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

Thiago Macieira thiago.macieira at intel.com
Wed May 3 14:59:17 CEST 2017

Em quarta-feira, 3 de maio de 2017, às 04:28:30 PDT, René J. V. Bertin 
> Thiago Macieira wrote:
> > The commercial client will complain to paid support, support will
> > investigate the issue and figure out what the regression is.
> And if they can't reproduce it either?

Then they don't have a problem.

> > In 5.8, the build deadlocks, so
> > we can't even just disable a test.
> How is that even possible?

Beats me. It just did the last two times we tried to stage the fix through the 

> > We'd have to disable all of the code that
> > uses qdbusxml2cpp, like dbusmenu and dbustray. That's not acceptable.
> Or you figure out a way to deactivate the venom part of the patch that
> causes the CI issue, when building on the CI. A bit like how Volkswagen
> detected testing cycles and activate certain required injection
> modifications in that case :)

Be my guest if you have any ideas. I'm fresh out of them (and have been for a 

> Do I have to understand that the CI system also creates the official
> installer binaries?

Yes, it uses the same system.

> >> If the regression is not a false alarm you'll end up getting a bug report
> > 
> > It's not a false alarm. IT's reliably reproduceable in the CI.
> That doesn't necessarily mean that it means anything. A CI is supposed to be
> representative of a standard user system but can fail to be.

True, but it can be reliably reproduced in one system.

Of course, experience with Linux distributions shipping the patches indicates 
that the deadlock does not happen for everyone.

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

More information about the Development mailing list