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

[René J.V. Bertin]

Hello,

Together with the principal maintainer I am looking into issues in a style plugin related to its use of DBus (to be informed of desktop-wide changes):

https://bugs.kde.org/show_bug.cgi?id=363753

The ticket above is about a reproducible issue in a custom cleanup handler that is designed to disconnect from the session DBus when the style plugin is unloaded. This mostly works fine but there are cases where a crash occurs inside QDBusConnection::sessionBus() (looks like accessing a deleted class instance). The documentation for that function does not mention anything about situations where the function is unsafe to be called.

There is a second, underlying issue which is the reason why the cleanup handler was designed. Apparently it is possible for DBus signals to arrive *after* the style plugin was dlclose'd (unmapped?) without having first deleted all existing style instances (QCommonStyle subclass). It seems that the time slot in which this is possible ought to be very short, but if signals do come in the application jumps into "unmapped code" which evidently causes a crash.

It is surprising that Qt unloads the style plugin without having first deleted the style instances, esp. when those instances are not created directly by user and there is not a single such instance (typically I see 5 - 7 instances being created).

We're currently testing an approach in which the style plugin and style keep track of the number of instances created and delete all remaining copies before unloading the plugin (and in addition the DBus disconnect is also triggered through QCoreApplication::aboutToQuit). That seems excessive.

At first glance one could consider this as 2 bugs in Qt; a missing verification in QDBusConnection::sessionBus() and allowing style plugins to be unloaded before all known style instances have been deleted.

Before we file bug report(s) though I'd like to be certain these are not known issues, and that we're not doing something wrong in our code. 

Thanks,
René