QDBusConnectionManager hanging on exit

[DalePennington]

Folks,

I have a fairly complicated app that uses DBus (have QT += dbus in .pro file).

During app startup, one of the other libraries (that does not use DBus) hits an error condition and calls exit(). At this point, none of the in app DBus code has been called.

But the app is handing on exit. When I hook gdb into the process, there is only 1 thread running, and the top of the stack has :

in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /lib64/libQt5Core.so.5
in QWaitCondition::wait(QMutex*, unsigned long) () for /lib64/libQt5Core.so.5
in QThread::wait(unsigned long) () from /lib64/libQt5Core.so.5
in QDBusConnectionManager::~QDBusConnectionManager() () from /lib64/libQtDBus.so.5
in (anonymous_namespace)::Q_QGS__q_manager::innerFunction()::Holder::~Holder() () from /lib64/libQtDBus.so.5
in _run_exit_handlers () from /lib64/libc.so.6
in exit () from /lib64/libc.so.6
in <third party libary init function that called exit>
<rest of stack>

This is on a RHEL 8 system using QT 5.12.5

What I am wondering is if anyone else has encountered this issue and if there is a known workaround/fix. If not, then I guess I will need to generate a bug report.

Thanks,
Dale Pennington

[SGaist]

Hi,

Would it be possible to initialize that library before you start the Qt part of your application ?

[DalePennington]

Not conviently at this point, as it is buried down in some general initialization code that may have other parts depending on QT.

[SGaist]

Is that second library something you can modify ?

[DalePennington]

Nope, it is strictly a third party library. We have no source code access. I may be able to hack out code a bit on initialization for testing, but would most likely not want it in production code.

Trying that is on my list in the next couple of days.

[DalePennington]

OK, I managed to hack the code to do the third party library initialization before instantiation the QApplication. In that case there was not a hang on exit.

This does seem to indicate a QT issue where they set up what is needed for DBus, but do hang if exit occurs before any DBus connection is made.

Unfortunately, this hack is not valid for production code, as we actually depend on configuration parameters that we load during our Application class creation. I did a temp hardcode to know good lab value, but that would not work in the field.

Dale

[SGaist]

Did you already check the bug report system for that issue ?

[DalePennington]

I did a search and did not see anything that looked applicable. I know we do not see this behavior in the QT4 version of the app, which has the same code, so I suspect this is a new to QT5 behavior.

[SGaist]

Then you should open a new report and if possible please provide a minimal compilable example that reproduces this.

[mr.bachmann]

Hello Dale,
would it be possible for you to share what you did to make it work?
Even though you call it a hack it would be interesting to see how it is possible to prevent the code from hanging during shutdown.