[Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[René J.V. Bertin]

On Friday April 28 2017 12:27:48 Shawn Rutledge wrote:

>That says that this fixes it https://codereview.qt-project.org/#/c/161056/ and that in turn says that https://codereview.qt-project.org/#/c/180232/ is the equivalent for 5.8.  So I suppose we’d better get it into 5.9 then, right?  

Dang, that happens with huge and long-lived tickets like this: I forgot about that patch. That may explain too why I'm not seeing the crash myself...

>Writing a bug doesn’t hurt anything, and in fact will help to make the case that the patch is urgently required.
>
>But are you convinced that it’s the right fix?

Convinced it's THE right and ONLY fix, no, I don't have enough experience in this context to be that affirmative. I am pretty convinced though that it'd be a very good idea to add protections that make it safe to use QtDBus during global destruction after "QtDBus has already destroyed its internals".  That's all the more important if you cannot easily test whether global destruction is going on.

Will that also protect against incoming DBus signals? I guess not because the very fact those are apparently handled suggests that QtDBus is still up and running. But note that I haven't seen a representative backtrace of that kind of event yet.

I'll try to find some time to write a proper report this weekend then. It might also help provide a(nother) test-case to trigger DBus-related crashes. One that needs KF5 applications, but QtCurve itself can be built without KF5 dependencies and should be just as vulnerable.

On a related note: does QCoreApplication::startingUp() provide a proper starting-up equivalent for QCoreApplication::aboutToQuit ("QCoreApplication::readyToRoll", signal or method)? If multiple style instances are being created outside of our control we could at least try not to do DBus connections from the instances that aren't going to be used...

R.