Summary: | Amarok crash on exit | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Eelko Berkenpies <fedora> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | edward.hades, gmlastik, illogical1, myriam |
Priority: | HI | ||
Version: | 2.0-SVN | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Bugtrace for crash on exit |
Description
Eelko Berkenpies
2008-11-14 09:34:33 UTC
Yes, I'm getting the crash too. But sorry, this backtrace is useless. It's very hard to debug such crashes on exit, exactly because of the problem that you can never get a proper backtrace :( This is definitely a regression that was introduced after Beta 2 (or Beta 3?). Acknowledged, I didn't realize you were referring to my "broken" backtrace earlier on the mailinglist. :) If anything changes or if I can manage to get something else out of it, I'll let you know. As far as I can remember this bug got introduced with SNV Changelog being updated to reflect RC1. Can't remember having/seeing this problem before that. I have a suspicion: These problems started around the time we switched to MySQL Embedded. And now I saw this on Amarok shutdown: amarok: END__: virtual App::~App() - Took 0.22s amarok: Deinitialized thread, count== 2 So this code is executed after App is already destroyed, which might spell trouble. I traced this code down: src/collection/sqlcollection/MySqlEmbeddedCollection.cpp 70: debug() << "Deinitialized thread, count==" << threadsCount; Looking into that now. Created attachment 28572 [details]
Bugtrace for crash on exit
the posted backtrace is from a newly build Amarok 2 (build date 14.11.08) Another one: amarok: END__: virtual App::~App() - Took 0.13s amarok: Deinitialized thread, count== 2 *** glibc detected *** amarok: corrupted double-linked list: 0x098f8330 *** Application: Amarok (amarok), signal SIGABRT [Thread debugging using libthread_db enabled] [New Thread 0xb3ac5900 (LWP 10656)] [New Thread 0xacdfdb90 (LWP 10666)] [New Thread 0xad5feb90 (LWP 10665)] [New Thread 0xaddffb90 (LWP 10664)] [New Thread 0xaf7e5b90 (LWP 10663)] [KCrash handler] #6 0xb801f430 in __kernel_vsyscall () #7 0xb4c3e880 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb4c40248 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb4c7c10d in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb4c823f4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4c85472 in ?? () from /lib/tls/i686/cmov/libc.so.6 #12 0xb4c86865 in malloc () from /lib/tls/i686/cmov/libc.so.6 #13 0xb7e0ef5d in qMalloc () from /usr/lib/libQtCore.so.4 #14 0xb7e18043 in QByteArray::resize () from /usr/lib/libQtCore.so.4 #15 0xb7f38cbc in ?? () from /usr/lib/libQtCore.so.4 #16 0xb7f34c09 in QTextCodec::fromUnicode () from /usr/lib/libQtCore.so.4 #17 0xb7e583eb in QString::toLocal8Bit () from /usr/lib/libQtCore.so.4 #18 0xb7e92169 in ?? () from /usr/lib/libQtCore.so.4 #19 0xb7e91f0a in QFile::encodeName () from /usr/lib/libQtCore.so.4 #20 0xb7ab294f in KStandardDirs::exists () from /usr/lib/libkdecore.so.5 #21 0xb7ab7b56 in KStandardDirs::findResourceDir () from /usr/lib/libkdecore.so.5 #22 0xb7b24512 in ?? () from /usr/lib/libkdecore.so.5 #23 0xb7b2c34d in ?? () from /usr/lib/libkdecore.so.5 #24 0xb7b2c80c in KLocale::removeCatalog () from /usr/lib/libkdecore.so.5 #25 0xb7ab2481 in KComponentData::~KComponentData () from /usr/lib/libkdecore.so.5 #26 0xb7b91500 in KPluginFactory::~KPluginFactory () from /usr/lib/libkdecore.so.5 #27 0xae0a9f42 in ~factory (this=0x8d2aab0) at /home/mark/kde/src/amarok/src/context/engines/current/CurrentEngine.h:95 #28 0xb7f1d487 in QObjectCleanupHandler::clear () from /usr/lib/libQtCore.so.4 #29 0xb7f1d4e0 in QObjectCleanupHandler::~QObjectCleanupHandler () from /usr/lib/libQtCore.so.4 #30 0xb7b91025 in ?? () from /usr/lib/libkdecore.so.5 #31 0xb7a3e91b in ?? () from /usr/lib/libkdecore.so.5 #32 0xb4c41d69 in exit () from /lib/tls/i686/cmov/libc.so.6 #33 0xb4c2968d in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #34 0x08048e21 in _start () #0 0xb801f430 in __kernel_vsyscall () Not one to be left out, I'll add mine to the mix: Thread 0 Crashed: 0 ...collection-sqlcollection.so 0x1a67eddb my_thread_end + 43 1 ...collection-sqlcollection.so 0x1a65fd7a ThreadInitializer::~ThreadInitializer() + 26 2 ...collection-sqlcollection.so 0x1a65fe26 QThreadStorage<ThreadInitializer*>::deleteData(void*) + 22 (qthreadstorage.h:129) 3 QtCore 0x002c280d QThreadStorageData::finish(void**) + 269 4 QtCore 0x003aa841 QCoreApplicationPrivate::~QCoreApplicationPrivate() + 49 5 QtGui 0x03b641ca QApplicationPrivate::~QApplicationPrivate() + 202 6 QtCore 0x003be247 QObject::~QObject() + 1191 7 QtGui 0x03b5f621 QApplication::~QApplication() + 1409 8 libamaroklib.1.dylib 0x00b6f008 App::~App() + 616 9 0x00014a2d main + 12637 (main.cpp:129) 10 0x000113d2 _start + 216 11 0x000112f9 start + 41 SVN commit 885465 by markey: Downgrade libplasma to r878420. This seems to fix the crashing on exit. Big thanks to Gary Steinert for figuring this out. BUG: 175109 M +0 -1 CMakeLists.txt M +1 -2 plasma/CMakeLists.txt M +0 -1 plasma/Mainpage.dox M +11 -13 plasma/applet.cpp M +3 -2 plasma/applet.h M +4 -4 plasma/containment.cpp M +1 -8 plasma/corona.cpp M +1 -0 plasma/dataenginemanager.cpp M +2 -2 plasma/dialog.cpp M +11 -5 plasma/package.cpp M +1 -1 plasma/package.h M +4 -8 plasma/packagemetadata.cpp M +6 -7 plasma/packagemetadata.h M +1 -60 plasma/packagestructure.cpp M +1 -8 plasma/packagestructure.h M +1 -1 plasma/private/service_p.h M +30 -98 plasma/private/tooltip.cpp M +5 -6 plasma/private/tooltip_p.h M +1 -6 plasma/private/windowpreview.cpp M +0 -1 plasma/private/windowpreview_p.h M +40 -15 plasma/servicetypes/plasma-animator.desktop [TRAILING SPACE] M +9 -10 plasma/servicetypes/plasma-applet-extenderapplet.desktop M +44 -14 plasma/servicetypes/plasma-applet.desktop M +42 -20 plasma/servicetypes/plasma-containment.desktop [TRAILING SPACE] M +39 -13 plasma/servicetypes/plasma-dataengine.desktop M +32 -12 plasma/servicetypes/plasma-packagestructure.desktop M +45 -11 plasma/servicetypes/plasma-runner.desktop M +41 -18 plasma/servicetypes/plasma-scriptengine.desktop M +19 -10 plasma/servicetypes/plasma-wallpaper.desktop M +74 -34 plasma/tests/packagemetadatatest.desktop M +6 -6 plasma/tests/packagestructuretest.cpp M +7 -7 plasma/tests/plasmoidpackagetest.cpp M +1 -0 plasma/tests/testengine/CMakeLists.txt M +36 -15 plasma/tests/testengine/plasma-dataengine-testengine.desktop M +1 -2 plasma/theme.cpp D plasma/tooltipcontent.cpp D plasma/tooltipcontent.h M +100 -36 plasma/tooltipmanager.cpp M +32 -5 plasma/tooltipmanager.h M +2 -2 plasma/wallpaper.cpp M +1 -1 plasma/widgets/frame.h M +4 -8 plasma/widgets/tabbar.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=885465 shouldn't we rather reassign this to the plasma team? @illogic-al you realize that we are using a relatively old snapshot of liplasma and that this particular issue is probably no longer relevant? No, you don't :) If that were true why downgrade and not upgrade? This is getting a bit tiresome, cause you're missing the big picture. Try to upgrade it and you shall see. No, you're ignoring the big picture because you can't be arsed. Nor can I. At least I can just come out and say so. |