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

[Thiago Macieira]

Em sexta-feira, 5 de maio de 2017, às 01:47:53 PDT, René J. V. Bertin 
escreveu:
> Thiago Macieira wrote:
> >> Indeed. Does it even need to link to QtDbus then?
> > 
> > It links to QtBootstrapDBus.
> 
> That looks like an internal library which itself links to QtDBus, right?

No, it's a bootstrapped version of QtDBus so that qdbusxml2cpp and 
qdbuscpp2xml can be bootstrapped too and run as a host binaray during cross-
compilation.

It's also built during a regular -developer-built but not used by anything, 
just so that I wouldn't make changes that would break that bootstrapped built, 
which like I said I never use.

> Some more thoughts how to work around this:
> - include only those required bits and pieces into QtBootstrapDBus rather
> than linking to QtDBus. If the connection-related code isn't required maybe
> the issue goes away when that code is removed.

That's already how it is.

> - do a bogus DBus connect (on ARM) or at least call
> QtDBusConnection::sessionBus() so there is something to clean up.

There's no connect in the first place. QtBootstrapDBus is just the XML parsing 
and metaobject generation code, along with the base metatype support. It's 
that base metatype support that was affected by one of the patches and must be 
the reason why the deadlock happens.

> The most "just" approach might be something like this:
> - find a way to deactivate the patch on ARM and wait until an ARM user
> complains about the issue it fixes. It could be just as unlikely that
> someone will run into the original issue on ARM as someone running into the
> build issue because of the patch.

Be my guest. I can't test this, so I don't have a way to even try whether it 
worked. I won't waste my time and my reviewes' time by submitting patches, 
waiting for +2, then staging only to find out that it doesn't fix anything.

> If we assume that there is now enough indication that the patch is required
> on Intel; with this approach you wouldn't be withholding it because of a
> potential issue on ARM.

The patch is required everywhere, as you've found out. Without it, QtDBus 
applications crash on exit.

> I'll try to figure out if the Debian QtCurve package maintainer(s) know
> whether they ever encountered the original crash-on-exit on ARM.

Because it's not architecture dependent. I told you yesterday, "The problem 
happens before any ARM code is run, so it's not an emulation or processor 
issue. It must be a cross-compilation (bootstrapping) issue."

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center