https://bugs.kde.org/show_bug.cgi?id=363753
--- Comment #52 from Yichao Yu <yyc1...@gmail.com> --- Yes the latest version looks fine though I'd like to test it for some time. > but if I understand the DBus protocol well enough they'd have to send exactly > the "right" signals (one of those QtCurve subscribes to) and exactly at the > "right" moment. That seems a bit far-fetched. It's more complicated than that. IIRC the segfault happens when the qdbus connection walks some internal data structures for dispatch, which touches some unmapped memory (vtables and alike). > the overall complexity of KDE and Qt is becoming so big that it's not always > possible to do certain things like proper clean up because of race conditions. I hope that's not the case but maybe it is.... > That's probably why Qt no longer unloads (all) plugins explicitly. Except > apparently the style plugin, or that too is handled by some automagic > mechanism. Hmmm. That's interesting because I've never seen anything being unloaded before 5.8 (or 5.7?). > Presuming that each dlopen adds to a counter that prevents unmapping and each > dlcose decreases that counter you could do it in the Style ctor and dtor. Yes. If I can find the right function... > But are you sure the unmapping was performed by Qt? I've never looked into > this aspect of the code but I would expect them at most to dlclose libraries > and plugins. That should of course also invalidate the image of the library > to some degree but not necessarily unload everything. What Qt does is of course `dlclose`, the unmmap I've seen happens in the dlclose call. > Maybe your kernel is configured to do very strict cleanup, or RAM is so tight > that it tends to unload resources that are no longer needed immediately? I was hopping this to be a glibc thing but those low level detail is beyong me. > But: it'd be a severe bug if Qt somehow unloaded or even dlclosed a plugin > before having destroyed all class instances created through it. It's clearly doing the dlclose before they destructed the Style* > I've never seen an example showing that code must delete Style instances > itself, so I think the application instance takes ownership. It almost feels like that Qt should delete all QObjects before deleting the style plugin but that also seems like a terrible idea.... > If that also means that the file is completely removed from memory will > probably depend on circumstances, but should be a moot question. Right, my confusing is just that why it sometimes (well, previously) unmmap and sometimes not.... >> __attribute__((destructor)) function attributes. See the gcc info >> pages for information on these. Con‐ This I'm acutally not worrying too much. I still have a faith that the plugin destructor will be closed before dlclose (confirmed in the debugger) so using it as the last resort should still be ok. > You could add some trace output to stderr (better not via Qt code ;)) in the > library destructor and see if that confirms your hypothesis (let it print the > number of plugin and style instances that are still open, for instance). I have confirmed in the debugger that the single dlopen on qtcurve have been dlclosed. I might get a glibc with debug simple and check internal logic later... > Other things to do (as soon as you can reproduce the crash) would be to Let's hope I don't and the patch just work......................... > I have never seen a backtrace of the kind of crash you are seeing, but I > think that with my current implementation you should no longer be seeing it. I actually mean the stack trace in this bug report, not mine. For that I agree that adding a safe guard that's called earlier (i.e. abouttoquit) should work. -- You are receiving this mail because: You are watching all bug changes.
