If you use the async dbus bindings and dbus crashes, qtdbus crashes as well if you try to call any dbus-related functions. This is caused by the QDBusConnectionPrivate class. Example Backtrace from net-misc/nut: #0 QMetaObject::activate (sender=0x5f006e, m=<value optimized out>, local_signal_index=1, argv=0x7fffbbed81d0) at kernel/qobject.cpp:3190 #1 0x00007fd64f19d83a in QDBusConnectionPrivate::callWithCallbackFailed (this=0x7fd64f3b2e20, _t1=<value optimized out>, _t2=<value optimized out>) at .moc/release-shared/moc_qdbusconnection_p.cpp:112 #2 0x00007fd64f1656e0 in QDBusConnectionPrivate::processFinishedCall (call=0x7ec990) at qdbusintegrator.cpp:1694 #3 0x00007fd64f16abfb in QDBusConnectionPrivate::sendWithReplyAsync (this=0x73adc0, message=<value optimized out>, receiver=0x8f4070, returnMethod=0x49be00 "1dbret_getDeviceList(QList< QDBusObjectPath >)", errorMethod=0x49bb60 "1dbret_errorOccured(QDBusError)", timeout=<value optimized out>) at qdbusintegrator.cpp:1904 #4 0x00007fd64f15446a in QDBusConnection::callWithCallback (this=0x8f5380, message=@0x5, receiver=0x0, returnMethod=0x4 <Address 0x4 out of bounds>, errorMethod=0x8ca730 "�R\217", timeout=1295768064) at qdbusconnection.cpp:461 #5 0x00007fd64f172059 in QDBusAbstractInterface::callWithCallback (this=<value optimized out>, method=@0x7fffbbed84c0, args=@0x7fffbbed84d0, receiver=0x8f4070, returnMethod=0x49be00 "1dbret_getDeviceList(QList< QDBusObjectPath >)", errorMethod=0x49bb60 "1dbret_errorOccured(QDBusError)") at qdbusabstractinterface.cpp:471 #6 0x0000000000464b8c in libnutclient::DBusDeviceManagerInterface::getDeviceList (this=0x8f4070) at server_proxy.cpp:22
Created attachment 195644 [details, diff] Fixes the bug in qt-dbus This should fix the bug (at least it worked for me)
Can you report this bug on qt tracker as well? Thanks http://www.qtsoftware.com/developer/task-tracker
Done. I'll post the bug-id when they send me one (at least I haven't found one after reporting).
Any updates here?
(In reply to comment #4) > Any updates here? > Not yet. They didn't send me a bug-id. I don't think they've fixed it yet (in 4.5.3), though I didn't have a close look at it. I'll test it later (have to emerge qt-4.5.3 and that takes some time @1.73ghz).
Could you attach a test case which reproduces the crash? Otherwise please explain how to reproduce it...
(In reply to comment #6) > Could you attach a test case which reproduces the crash? Otherwise please > explain how to reproduce it... > Hi, I guess there's a very easy way to reproduce this (though im not 100% sure it's the same bug). Have KDE4 running, xorg without hal and as root kill dbus (killall dbus-daemon). Have fun. At least on my box with qt-4.5.3 it crashed almost all kde4 apps with a segfault (that's why I guess that it's the same bug or at least they're some kind of equal as both occure in the async dbus implementation). You might have to wait some time (about 30 seconds). I'll recompile qt with this patch next week.
OK, I could reproduce with Qt 4.6.1, although the backtrace looked quite different. Daniel, can you retry opening a bug upstream please? This time use their new bug tracker at http://bugreports.qt.nokia.com/secure/Dashboard.jspa
(In reply to comment #8) > OK, I could reproduce with Qt 4.6.1, although the backtrace looked quite > different. > Daniel, can you retry opening a bug upstream please? This time use their new > bug tracker at http://bugreports.qt.nokia.com/secure/Dashboard.jspa > I have checked the source of qt-4.5.3 and qt seemed to have fixed this particular bug. The problem is somewhere else now. I'll create a backtrace and report this upstream.
Great, thanks. That explains why I was seeing different backtraces. Anyway I guess most applications don't expect the dbus daemon to crash...
Nothing we can do here, this must be fixed upstream.
