Version: (using KDE 4.4.2) Compiler: GCC OS: Linux Installed from: Ubuntu Packages The Kfile plugin for Qt4 triggers registration of the destructor for the global static KIOScheduler, if the Qt4 open dialog is invoked (from a Qt4 but non-KDE application). This causes a crash at exit, while glibc runs the exit handlers. Apparently, ~KIOScheduler tries to use QDBus (which is already deinitialized). Ubuntu apport has recorded many occurence of this issue here: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/408719
KDE SC 4.5 has a completely new implementation of the KIO scheduler (see http://websvn.kde.org/?revision=1075343&view=revision for the changes). Could you check if this fixed the VLC issue?
If you can provide the information requested in comment #1, please add them to this bug report.
I tried with KDE 4.5.1 as provided in Kubuntu 10.10, and I still get the exact same crash in QDBus from ~KIOScheduler from the exit handlers.
It would be nice if you could provide an updated backtrace, because the old backtrace from comment #0 contains references to code that is no longer present.
With KDE 4.5.1, I get this: Program received signal SIGSEGV, Segmentation fault. 0x0193aaa6 in QDBusAdaptorConnector::relaySlot (this=0x84008d8, argv=0xbffff088) at qdbusabstractadaptor.cpp:270 270 qdbusabstractadaptor.cpp: Aucun fichier ou dossier de ce type. in qdbusabstractadaptor.cpp (gdb) bt #0 0x0193aaa6 in QDBusAdaptorConnector::relaySlot (this=0x84008d8, argv=0xbffff088) at qdbusabstractadaptor.cpp:270 #1 0x0193ab24 in QDBusAdaptorConnector::qt_metacall (this=0x84008d8, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbffff088) at qdbusabstractadaptor.cpp:366 #2 0x016dd8ca in QMetaObject::metacall (object=0x84008d8, cl=3221221512, idx=4, argv=0xbffff088) at kernel/qmetaobject.cpp:237 #3 0x016f06ad in QMetaObject::activate (sender=0x8400740, m=0x1805230, local_signal_index=0, argv=0x84008d8) at kernel/qobject.cpp:3280 #4 0x016f0bd3 in QObject::destroyed (this=0x8400740, _t1=0x8400740) at .moc/release-shared/moc_qobject.cpp:149 #5 0x016f1afa in QObject::~QObject (this=0x8400740, __in_chrg=<value optimized out>) at kernel/qobject.cpp:842 #6 0x0228225d in KIO::Scheduler::~Scheduler (this=0x8400740, __in_chrg=<value optimized out>) at ../../kio/kio/scheduler.cpp:766 #7 0x02288844 in ~SchedulerPrivate () at ../../kio/kio/scheduler.cpp:667 #8 destroy () at ../../kio/kio/scheduler.cpp:730 #9 0x021cf8eb in KCleanUpGlobalStatic::~KCleanUpGlobalStatic (this=0x239c1f0, __in_chrg=<value optimized out>) at ../../kdecore/kernel/kglobal.h:62 #10 0x002f469e in __run_exit_handlers (status=0, listp=0x41f324, run_list_atexit=true) at exit.c:78 #11 0x002f470f in exit (status=0) at exit.c:100 #12 0x002dbcef in __libc_start_main (main=0x8048e60 <main>, argc=1, ubp_av=0xbffff2c4, init=0x8049d90 <__libc_csu_init>, fini=0x8049d80 <__libc_csu_fini>, rtld_fini=0x11eac0 <_dl_fini>, stack_end=0xbffff2bc) at libc-start.c:258 #13 0x08048da1 in _start ()
Can you provide an efficient way of reproduce this bug and a valgrind trace? Thanks.
valgrind: (8449) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-remi/ksycoca4" kfilemodule(8449)/kdecore (services) KMimeTypeFactory::parseMagic: Now parsing "/usr/share/mime/magic" kfilemodule(8449)/kdecore (services) KMimeTypeFactory::parseMagic: Now parsing "/home/remi/.local/share/mime/magic" ==8449== Thread 1: ==8449== Invalid read of size 4 ==8449== at 0x8C14CE6: QDBusAdaptorConnector::relaySlot(void**) (qdbusabstractadaptor.cpp:268) ==8449== by 0x8C15683: QDBusAdaptorConnector::qt_metacall(QMetaObject::Call, int, void**) (qdbusabstractadaptor.cpp:364) ==8449== by 0x72AE7A9: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:237) ==8449== by 0x72BD1BA: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3295) ==8449== by 0x72BD5F2: QObject::destroyed(QObject*) (moc_qobject.cpp:149) ==8449== by 0x72BF9D9: QObject::~QObject() (qobject.cpp:869) ==8449== by 0x7A25FAC: KIO::Scheduler::~Scheduler() (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x7A29B00: ??? (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x795C32A: ??? (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x419007E: __run_exit_handlers (exit.c:78) ==8449== by 0x41900EE: exit (exit.c:100) ==8449== by 0x4177C7D: (below main) (libc-start.c:260) ==8449== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==8449== ==8449== ==8449== Process terminating with default action of signal 11 (SIGSEGV) ==8449== Access not within mapped region at address 0x4 ==8449== at 0x8C14CE6: QDBusAdaptorConnector::relaySlot(void**) (qdbusabstractadaptor.cpp:268) ==8449== by 0x8C15683: QDBusAdaptorConnector::qt_metacall(QMetaObject::Call, int, void**) (qdbusabstractadaptor.cpp:364) ==8449== by 0x72AE7A9: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:237) ==8449== by 0x72BD1BA: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3295) ==8449== by 0x72BD5F2: QObject::destroyed(QObject*) (moc_qobject.cpp:149) ==8449== by 0x72BF9D9: QObject::~QObject() (qobject.cpp:869) ==8449== by 0x7A25FAC: KIO::Scheduler::~Scheduler() (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x7A29B00: ??? (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x795C32A: ??? (in /usr/lib/libkio.so.5.4.0) ==8449== by 0x419007E: __run_exit_handlers (exit.c:78) ==8449== by 0x41900EE: exit (exit.c:100) ==8449== by 0x4177C7D: (below main) (libc-start.c:260) ==8449== If you believe this happened as a result of a stack ==8449== overflow in your program's main thread (unlikely but ==8449== possible), you can try to increase the size of the ==8449== main thread stack using the --main-stacksize= flag. ==8449== The main thread stack size used in this run was 8388608. ==8449== ==8449== HEAP SUMMARY: ==8449== in use at exit: 1,559,796 bytes in 25,684 blocks ==8449== total heap usage: 1,313,322 allocs, 1,287,638 frees, 248,976,827 bytes allocated ==8449== ==8449== LEAK SUMMARY: ==8449== definitely lost: 591 bytes in 6 blocks ==8449== indirectly lost: 160 bytes in 12 blocks ==8449== possibly lost: 953,762 bytes in 16,692 blocks ==8449== still reachable: 605,283 bytes in 8,974 blocks ==8449== suppressed: 0 bytes in 0 blocks ==8449== Rerun with --leak-check=full to see details of leaked memory ==8449== ==8449== For counts of detected and suppressed errors, rerun with: -v ==8449== Use --track-origins=yes to see where uninitialised values come from ==8449== ERROR SUMMARY: 64 errors from 5 contexts (suppressed: 482 from 13) Erreur de segmentation I just start VLC, go to Media / Open file, cancel and then Media / Quit. This assumes the libkde.so GUI platform for Qt is active.
I'm trying to reproduce this bug, within a full KDE session and in fluxbox, and so far I can't :/ can you provide more details about your environment? maybe an "env" output could provide some hints. Thanks.
I can confirm VLC 1.1.7 crash on exit in KDE 4.6.0 http://nucleo.fedorapeople.org/vlc-1.1.7.gdb
(In reply to comment #8) I can reproduce crash with this steps: 1. Start vlc. 2. Press Ctrl+O and then Cancel. 3. Close vlc window.
*** Bug 266872 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Version: (using KDE 4.4.2) > Compiler: GCC > OS: Linux > Installed from: Ubuntu Packages > > The Kfile plugin for Qt4 triggers registration of the destructor for the global > static KIOScheduler, if the Qt4 open dialog is invoked (from a Qt4 but non-KDE > application). > > This causes a crash at exit, while glibc runs the exit handlers. Apparently, > ~KIOScheduler tries to use QDBus (which is already deinitialized). You got that backwards. It is not KIO::Scheduler that attemtps to use QDBus, it is QDBus that attempts to access an already destroyed object which should not happen at all. Besides the backtraces that show otherwise, if you simply defer the deletion of the scheduler object using "q->deleteLater()" instead "delete q" in ~SchedulerPrivate, you would see that the crash goes away. As such the problem is upstream in QtDBus and friends. So long as a class register itself with QDBus, it will crash when accessed in the same manner as one that happens through VLC. For those interested in testing the workaround patch for this crash can be found at https://git.reviewboard.kde.org/r/100577. The reason that workaround is not committed is because Thiago said stated that he wanted to look into the cause of this problem. See http://lists.kde.org/?l=kde-core-devel&m=129693527318658&w=2
Created attachment 58893 [details] workaround patch... Here is Thiago's response: http://lists.kde.org/?l=kde-core-devel&m=130268229205730&w=2 Since this is not a KDE issue and I rather avoid committing workarounds for bugs that are not KDE's fault, even when they cause crash, I have attached the workaround patch for those that want to apply it with Qt 4.7 and whatever the recent version of VLC is (v1.1.9 for me).
*** Bug 267962 has been marked as a duplicate of this bug. ***
For other program but with like call QT mechanism I have backtrace for the error: (gdb) bt #0 0x00007f927bbd26fb in QDBusAdaptorConnector::relaySlot (this=0x2941280, argv=0x7fffd1abfc40) at qdbusabstractadaptor.cpp:270 #1 0x00007f927bbd2a05 in QDBusAdaptorConnector::qt_metacall (this=0x2941280, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffd1abfc40) at qdbusabstractadaptor.cpp:366 #2 0x00007f928697947d in QMetaObject::activate (sender=0x29413d0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x7fffd1abfc40) at kernel/qobject.cpp:3283 #3 0x00007f928697988f in QObject::destroyed (this=<value optimized out>, _t1=0x29413d0) at .moc/release-shared/moc_qobject.cpp:149 #4 0x00007f928697b975 in QObject::~QObject (this=0x29413d0, __in_chrg=<value optimized out>) at kernel/qobject.cpp:843 #5 0x00007f9282037179 in KIO::Scheduler::~Scheduler() () from /usr/lib64/libkio.so.5 #6 0x00007f928203d487 in ?? () from /usr/lib64/libkio.so.5 #7 0x00007f9282039979 in ?? () from /usr/lib64/libkio.so.5 #8 0x00007f928ca4d221 in __run_exit_handlers (status=10, listp=0x7f928cd7b4a8, run_list_atexit=true) at exit.c:78 #9 0x00007f928ca4d275 in exit (status=43258496) at exit.c:100 #10 0x00007f928ca36c64 in __libc_start_main (main=0x4010c0 <main(int, char**, char**)>, argc=2, ubp_av=0x7fffd1abfe98, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffd1abfe88) at libc-start.c:258 #11 0x0000000000400ff9 in _start () at ../sysdeps/x86_64/elf/start.S:113 From the bt I see what: - QT call (QFileDialog::getSaveFileName()) to KDE4 the file name select plugin through qOverride mechanism where been create KIO::Scheduler::Scheduler() object. - Next, on finish, QT objects have been full free by delete QApplication(). - Next, QT-module of the program have been unlinked by dlclose(). - And after all that we have crash on freeing try for IO::Scheduler::Scheduler() which should be removed together with all QT infrastructure freeing by QApplication() delete. Who must be remove KIO::Scheduler::Scheduler()? P.S. And other bug. KDE4 override file dialog, from QFileDialog::getSaveFileName(), have not been localized and the warning have place on start: KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work At that time QColorDialog KDE4 override dialog work fine and full localized!
(In reply to comment #15) > For other program but with like call QT mechanism I have backtrace for the > error: > (gdb) bt > #0 0x00007f927bbd26fb in QDBusAdaptorConnector::relaySlot (this=0x2941280, > argv=0x7fffd1abfc40) at qdbusabstractadaptor.cpp:270 > #1 0x00007f927bbd2a05 in QDBusAdaptorConnector::qt_metacall (this=0x2941280, > _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffd1abfc40) > at qdbusabstractadaptor.cpp:366 > #2 0x00007f928697947d in QMetaObject::activate (sender=0x29413d0, m=<value > optimized out>, local_signal_index=<value optimized out>, argv=0x7fffd1abfc40) > at kernel/qobject.cpp:3283 > #3 0x00007f928697988f in QObject::destroyed (this=<value optimized out>, > _t1=0x29413d0) at .moc/release-shared/moc_qobject.cpp:149 > #4 0x00007f928697b975 in QObject::~QObject (this=0x29413d0, __in_chrg=<value > optimized out>) at kernel/qobject.cpp:843 > #5 0x00007f9282037179 in KIO::Scheduler::~Scheduler() () from > /usr/lib64/libkio.so.5 > #6 0x00007f928203d487 in ?? () from /usr/lib64/libkio.so.5 > #7 0x00007f9282039979 in ?? () from /usr/lib64/libkio.so.5 > #8 0x00007f928ca4d221 in __run_exit_handlers (status=10, listp=0x7f928cd7b4a8, > run_list_atexit=true) at exit.c:78 > #9 0x00007f928ca4d275 in exit (status=43258496) at exit.c:100 > #10 0x00007f928ca36c64 in __libc_start_main (main=0x4010c0 <main(int, char**, > char**)>, argc=2, ubp_av=0x7fffd1abfe98, init=<value optimized out>, > fini=<value optimized out>, rtld_fini=<value optimized out>, > stack_end=0x7fffd1abfe88) at libc-start.c:258 > #11 0x0000000000400ff9 in _start () at ../sysdeps/x86_64/elf/start.S:113 > > From the bt I see what: > - QT call (QFileDialog::getSaveFileName()) to KDE4 the file name select plugin > through qOverride mechanism where been create KIO::Scheduler::Scheduler() > object. > - Next, on finish, QT objects have been full free by delete QApplication(). > - Next, QT-module of the program have been unlinked by dlclose(). > - And after all that we have crash on freeing try for > IO::Scheduler::Scheduler() which should be removed together with all QT > infrastructure freeing by QApplication() delete. > > Who must be remove KIO::Scheduler::Scheduler()? I have no idea how you see any of that from the back trace snippet you posted, but as it has already been stated the original issue reported here is not a KDE bug. See comments #12 and #13 ; especially the link given in comment 13. > P.S. And other bug. KDE4 override file dialog, from > QFileDialog::getSaveFileName(), have not been localized and the warning have > place on start: > KGlobal::locale::Warning your global KLocale is being recreated with a valid > main component instead of a fake component, this usually means you tried to > call i18n related functions before your main component was created. You should > not do that since it most likely will not work Please do not mix unrelated bug reports. You are free to open another ticket for this issue if one already does not exist for it.
*** Bug 279013 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Hi all, I reported this bug here and here: * https://bugs.mageia.org/show_bug.cgi?id=1968 * https://trac.videolan.org/vlc/ticket/5148#comment:1 Was it reported to the Qt developers? Regards, -- Shlomi Fish
A possible similiar issue has been reported to the Qt developers, which also cores at "QDBusAdaptorConnector::relaySlot" as a result of a cross-thread delete of QDBusAbstractAdaptor. See the stacktrace.log at the bugreport: https://bugreports.qt.nokia.com/browse/QTBUG-18205 Might be the same issue.
I don't think it's the same issue, even though the stack traces end in the same function. The root causes for the problems are different. And QTBUG-18205 is invalid because of an earlier error in the application: you cannot delete an object from outside its thread.
Fixed in Qt 4.8, according to https://bugs.launchpad.net/kdelibs/+bug/408719/comments/21
Using VLC 1.1.12 on KDE 4.8rc1 with Qt 4.8.0, I can still reproduce the crash with the steps provided in comment #10, so it either is still not fixed in Qt 4.8, or the fix did not affect KDE. Is there a link to an open Qt bug? Program received signal SIGSEGV, Segmentation fault. 0xaec68807 in QDBusAdaptorConnector::relaySlot (this=0x8473160, argv=0xbfffef58) at /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:270 270 relay(d->currentSender->sender, d->currentSender->signal, argv); (gdb) bt #0 0xaec68807 in QDBusAdaptorConnector::relaySlot (this=0x8473160, argv=0xbfffef58) at /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:270 #1 0xaec68b27 in QDBusAdaptorConnector::qt_metacall (this=0x8473160, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfffef58) at /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:366 #2 0xb3794926 in QMetaObject::metacall (object=0x8473160, cl=QMetaObject::InvokeMetaMethod, idx=4, argv=0xbfffef58) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qmetaobject.cpp:245 #3 0xb37a8720 in QMetaObject::activate (sender=0x8473148, m=0xb3937cc4, local_signal_index=0, argv=0xbfffef58) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qobject.cpp:3566 #4 0xb37a9fc8 in QObject::destroyed (this=0x8473148, _t1=0x8473148) at .moc/debug-shared/moc_qobject.cpp:149 #5 0xb37a33d1 in QObject::~QObject (this=0x8473148, __in_chrg=<optimized out>) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qobject.cpp:844 #6 0xaf82cc5d in KIO::Scheduler::~Scheduler (this=0x8473148, __in_chrg=<optimized out>) at /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:777 #7 0xaf82cc97 in KIO::Scheduler::~Scheduler (this=0x8473148, __in_chrg=<optimized out>) at /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:779 #8 0xaf831583 in KIO::SchedulerPrivate::~SchedulerPrivate (this=0x84730a8, __in_chrg=<optimized out>) at /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:667 #9 0xaf82c956 in destroy () at /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:736 #10 0xaf781c5d in KCleanUpGlobalStatic::~KCleanUpGlobalStatic (this=0xaf9aac94, __in_chrg=<optimized out>) at /local/git/KDE/libs/kdelibs/kdecore/kernel/kglobal.h:62 #11 0xb7d48931 in __run_exit_handlers (status=0, listp=0xb7e80304, run_list_atexit=true) at exit.c:78 #12 0xb7d489bd in __GI_exit (status=0) at exit.c:100 #13 0xb7d3100b in __libc_start_main (main=0x8048ca0, argc=1, ubp_av=0xbffff194, init=0x80499c0, fini=0x8049a30, rtld_fini=0xb7fedca0 <_dl_fini>, stack_end=0xbffff18c) at libc-start.c:258 #14 0x080493cd in ?? () Backtrace stopped: Not enough registers or memory available to unwind further
(In reply to comment #23) > Using VLC 1.1.12 on KDE 4.8rc1 with Qt 4.8.0, I can still reproduce the crash > with the steps provided in comment #10, so it either is still not fixed in Qt > 4.8, or the fix did not affect KDE. > > Is there a link to an open Qt bug? Nope, but there is always the workaround patch I provided in comment #12 that defers the deletion of all static objects that register themselves with QDBusConnection. It fixes the problem, but it does not really address the question why QDBusConnection attempts to access an already deleted object. Perhaps this is the result of the fact that all these objects that cause such crashes are static objects ? Anyways, unregistering the object from the QDBusConnection before deletion does not help either ; so the issue remains an upstream issue until someone can show otherwise. > Program received signal SIGSEGV, Segmentation fault. > 0xaec68807 in QDBusAdaptorConnector::relaySlot (this=0x8473160, > argv=0xbfffef58) at > /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:270 > 270 relay(d->currentSender->sender, d->currentSender->signal, argv); > > (gdb) bt > #0 0xaec68807 in QDBusAdaptorConnector::relaySlot (this=0x8473160, > argv=0xbfffef58) at > /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:270 > #1 0xaec68b27 in QDBusAdaptorConnector::qt_metacall (this=0x8473160, > _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfffef58) at > /local/git/Qt/frameworks/qt/src/dbus/qdbusabstractadaptor.cpp:366 > #2 0xb3794926 in QMetaObject::metacall (object=0x8473160, > cl=QMetaObject::InvokeMetaMethod, idx=4, argv=0xbfffef58) at > /local/git/Qt/frameworks/qt/src/corelib/kernel/qmetaobject.cpp:245 > #3 0xb37a8720 in QMetaObject::activate (sender=0x8473148, m=0xb3937cc4, > local_signal_index=0, argv=0xbfffef58) at > /local/git/Qt/frameworks/qt/src/corelib/kernel/qobject.cpp:3566 > #4 0xb37a9fc8 in QObject::destroyed (this=0x8473148, _t1=0x8473148) at > .moc/debug-shared/moc_qobject.cpp:149 > #5 0xb37a33d1 in QObject::~QObject (this=0x8473148, __in_chrg=<optimized out>) > at /local/git/Qt/frameworks/qt/src/corelib/kernel/qobject.cpp:844 > #6 0xaf82cc5d in KIO::Scheduler::~Scheduler (this=0x8473148, > __in_chrg=<optimized out>) at > /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:777 > #7 0xaf82cc97 in KIO::Scheduler::~Scheduler (this=0x8473148, > __in_chrg=<optimized out>) at > /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:779 > #8 0xaf831583 in KIO::SchedulerPrivate::~SchedulerPrivate (this=0x84730a8, > __in_chrg=<optimized out>) at > /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:667 > #9 0xaf82c956 in destroy () at > /local/git/KDE/libs/kdelibs/kio/kio/scheduler.cpp:736 > #10 0xaf781c5d in KCleanUpGlobalStatic::~KCleanUpGlobalStatic (this=0xaf9aac94, > __in_chrg=<optimized out>) at > /local/git/KDE/libs/kdelibs/kdecore/kernel/kglobal.h:62 > #11 0xb7d48931 in __run_exit_handlers (status=0, listp=0xb7e80304, > run_list_atexit=true) at exit.c:78 > #12 0xb7d489bd in __GI_exit (status=0) at exit.c:100 > #13 0xb7d3100b in __libc_start_main (main=0x8048ca0, argc=1, ubp_av=0xbffff194, > init=0x80499c0, fini=0x8049a30, rtld_fini=0xb7fedca0 <_dl_fini>, > stack_end=0xbffff18c) at libc-start.c:258 > #14 0x080493cd in ?? () > Backtrace stopped: Not enough registers or memory available to unwind further
Created attachment 68440 [details] Valgrind trace with Qt 4.8 with full debugging information The interesting part before the crash is ==26284== Thread 1: ==26284== Invalid read of size 4 ==26284== at 0x4BB781DD: QDBusAdaptorConnector::relaySlot(void**) (qdbusabstractadaptor.cpp:270) ==26284== by 0x4BB7854B: QDBusAdaptorConnector::qt_metacall(QMetaObject::Call, int, void**) (qdbusabstractadaptor.cpp:366) ==26284== by 0x1BE98052: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:245) ==26284== by 0x1BEAE402: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3566) ==26284== by 0x1BEAFF46: QObject::destroyed(QObject*) (moc_qobject.cpp:149) ==26284== by 0x1BEA843D: QObject::~QObject() (qobject.cpp:844) ==26284== by 0x4A603DCB: KIO::Scheduler::~Scheduler() (scheduler.cpp:777) ==26284== by 0x4A603DFD: KIO::Scheduler::~Scheduler() (scheduler.cpp:779) ==26284== by 0x4A608A86: KIO::SchedulerPrivate::~SchedulerPrivate() (scheduler.cpp:667) ==26284== by 0x4A603AD9: ._229::destroy() (scheduler.cpp:736) ==26284== by 0x4A54C320: KCleanUpGlobalStatic::~KCleanUpGlobalStatic() (kglobal.h:62) ==26284== by 0x57895A0: __run_exit_handlers (in /lib64/libc-2.11.3.so) ==26284== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==26284== ==26284== ==26284== Process terminating with default action of signal 11 (SIGSEGV) ==26284== Access not within mapped region at address 0x8 ==26284== at 0x4BB781DD: QDBusAdaptorConnector::relaySlot(void**) (qdbusabstractadaptor.cpp:270) ==26284== by 0x4BB7854B: QDBusAdaptorConnector::qt_metacall(QMetaObject::Call, int, void**) (qdbusabstractadaptor.cpp:366) ==26284== by 0x1BE98052: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:245) ==26284== by 0x1BEAE402: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3566) ==26284== by 0x1BEAFF46: QObject::destroyed(QObject*) (moc_qobject.cpp:149) ==26284== by 0x1BEA843D: QObject::~QObject() (qobject.cpp:844) ==26284== by 0x4A603DCB: KIO::Scheduler::~Scheduler() (scheduler.cpp:777) ==26284== by 0x4A603DFD: KIO::Scheduler::~Scheduler() (scheduler.cpp:779) ==26284== by 0x4A608A86: KIO::SchedulerPrivate::~SchedulerPrivate() (scheduler.cpp:667) ==26284== by 0x4A603AD9: ._229::destroy() (scheduler.cpp:736) ==26284== by 0x4A54C320: KCleanUpGlobalStatic::~KCleanUpGlobalStatic() (kglobal.h:62) ==26284== by 0x57895A0: __run_exit_handlers (in /lib64/libc-2.11.3.so)
*** Bug 270164 has been marked as a duplicate of this bug. ***
*** Bug 281716 has been marked as a duplicate of this bug. ***
*** Bug 307514 has been marked as a duplicate of this bug. ***
It seems, the problem is still not resolved upstream. I observe Vlc 2.1.3 crash on exit with very similar symptoms each time. Backtrace: #0 0x00007fffdb1920bb in QDBusAdaptorConnector::relaySlot () from /usr/lib64/libQtDBus.so.4 #1 0x00007fffdb192435 in QDBusAdaptorConnector::qt_metacall () from /usr/lib64/libQtDBus.so.4 #2 0x00007fffed403df2 in QMetaObject::activate () from /usr/lib64/libQtCore.so.4 #3 0x00007fffed40469f in QObject::destroyed () from /usr/lib64/libQtCore.so.4 #4 0x00007fffed4049b3 in QObject::~QObject () from /usr/lib64/libQtCore.so.4 #5 0x00007fffdd4aa309 in KIO::Scheduler::~Scheduler() () from /usr/lib64/libkio.so.5 #6 0x00007fffdd4b5e3b in ?? () from /usr/lib64/libkio.so.5 #7 0x00007fffdd4b0a77 in ?? () from /usr/lib64/libkio.so.5 #8 0x00007ffff387add1 in __run_exit_handlers (status=0, listp=0x7ffff3bf4688, run_list_atexit=<optimized out>) at exit.c:78 #9 0x00007ffff387ae55 in __GI_exit (status=<optimized out>) at exit.c:100 #10 0x00007ffff386374c in __libc_start_main (main=0x401836 <main>, argc=1, ubp_av=0x7fffffffdb88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdb78) at libc-start.c:258 #11 0x00000000004015bd in _start () at ../sysdeps/x86_64/elf/start.S:113 OS: ROSA Fresh x64 Qt: 4.8.5 KDE: 4.12.3