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.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
