https://bugs.kde.org/show_bug.cgi?id=363753
--- Comment #50 from RJVB <rjvber...@gmail.com> --- (In reply to Yichao Yu from comment #48) > Yes it'll make you vulnerable but it won't actually crash unless some > unknown conditions are met. I suspect it's related to other plugins that are > also using dbus but I'm not sure. Usually I am the one running into seemingly inexplicable situations :) Yes, other plugins could be involved, 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. > Exactly. Good to know at least you can observe this. I can only say that > I've seen this leads to crashes before and I don't really think this should > happen. No it shouldn't but 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. 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. > Not sure why. (OTOH, another way to work around this is to dlopen the > library itself so that the dlclose won't actually unmmap the library code. > Not sure how that can be done though) 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. 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. 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? For the anecdote, I had a weird issue recently with QProcess where it would claim that commands failed to start while I could run them without any problem in a terminal. I finally traced that down to the fact I had deactivated "overcommit" (the Linux trick that pretends every memory allocation succeeds no matter how big it is). Asking around on the Qt development ML confirmed that there were known issues in Qt that could explain what I was seeing. 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. > = = .... I actually have no idea who created them and how the memory is > managed by either qt or the application Usually Qt itself, or the plasma-integration plugin, but some applications have a style selection feature (the oxygen-demo application currently in git/head, for instance). I've never seen an example showing that code must delete Style instances itself, so I think the application instance takes ownership. > hard for me to tell if any alternative solution can work........ I'm > checking why is dlclose not unmapping the library, though don't expect that > to be very easy.... No, as I said this is probably under very lowlevel system control; `man dlclose` just says that the library is "unloaded" when the library handle load count drops to 0. If that also means that the file is completely removed from memory will probably depend on circumstances, but should be a moot question. >From `man dlclose`: > Instead, libraries should export routines using the > __attribute__((constructor)) and > __attribute__((destructor)) function attributes. See the gcc info > pages for information on these. Con‐ > structor routines are executed before dlopen() returns, and > destructor routines are executed before > dlclose() returns. 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). Other things to do (as soon as you can reproduce the crash) would be to - test with other styles - if that stops the crash QtCurve must be doing something wrong - test without the plasma integration plugin > 5.8.0 ATM Same here. > Sure, I'll be certainly fine with that. Though given many (all?) of the > backtrace points to `QDBusConnection::sessionBus` I don't think that'll > solve the problem... 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. As long as all plugin instances are deleted all Style instances will be deleted too, and they'll disconnect from DBus during that operation. In addition they'll disconnect when the application instance is taken down. This way nothing allocated/created through QtCurve should remain in memory that can wreak havoc when the library is unloaded (something your implementation couldn't guarantee). Not all of Qt is "fool proof", the code cannot possibly check for everything that goes wrong. In this case we are apparently using QDBusConnection::sessionBus() in a context where we shouldn't be calling it. It might be worthwhile to file a Qt bug report; that might be the best way to get an assessment whether or not we're doing something in a way we shouldn't be doing it. But I'd wait a bit; theoretically my current patch should lead to near-identical situations when delete'ing Style instances from the plugin dtor - and it'll be somewhat easier to describe. -- You are receiving this mail because: You are watching all bug changes.
