Application that crashed: amarok Version of the application: 2.3-GIT KDE Version: 4.3.5 (KDE 4.3.5) "release 0" Qt Version: 4.5.3 Operating System: Linux 2.6.31.12-0.2-desktop x86_64 Distribution: "openSUSE 11.2 (x86_64)" What I was doing when the application crashed: Reproducing bug #228219 on GIT-2.3 (as of 2010-03-22/23?) Happens when I hit the close button on a USB collection (MSC), probably while it is still scanning. -- Backtrace: Application: Amarok (amarok), signal: Segmentation fault [Current thread is 1 (Thread 0x7f4003c247a0 (LWP 29865))] Thread 12 (Thread 0x7f3fee998910 (LWP 29866)): #0 0x00007f400085b2cd in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f3ff0076511 in ?? () from /usr/lib64/libxine.so.1 #2 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #3 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 0x7f3feca2a910 (LWP 29867)): #0 0x00007f4000d8bd03 in poll () from /lib64/libc.so.6 #1 0x00007f3ffa38959c in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007f3ffa3898e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007f400223f3f6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #4 0x00007f4002215712 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #5 0x00007f4002215ae4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #6 0x00007f400212e71b in QThread::exec() () from /usr/lib64/libQtCore.so.4 #7 0x00007f3ff02d1394 in Phonon::MediaSource::type() const () from /usr/lib64/kde4/plugins/phonon_backend/phonon_xine.so #8 0x00007f4002131485 in ?? () from /usr/lib64/libQtCore.so.4 #9 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #10 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 10 (Thread 0x7f3fec01f910 (LWP 29870)): #0 0x00007f4000d87acb in read () from /lib64/libc.so.6 #1 0x00007f3ff07502f5 in ?? () from /usr/lib64/libasound.so.2 #2 0x00007f3ff074b058 in snd_hctl_handle_events () from /usr/lib64/libasound.so.2 #3 0x00007f3ff0754da9 in snd_mixer_handle_events () from /usr/lib64/libasound.so.2 #4 0x00007f3fec025c94 in snd_pcm_sw_params_set_start_threshold () from /usr/lib64/xine/plugins/1.25/xineplug_ao_out_alsa.so #5 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #6 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #7 0x0000000000000000 in ?? () Thread 9 (Thread 0x7f3feb81e910 (LWP 29871)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f3ff0087513 in ?? () from /usr/lib64/libxine.so.1 #2 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #3 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 8 (Thread 0x7f3feaa07910 (LWP 29872)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f3ff0087513 in ?? () from /usr/lib64/libxine.so.1 #2 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #3 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 7 (Thread 0x7f3fea206910 (LWP 29873)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f3ff0087513 in ?? () from /usr/lib64/libxine.so.1 #2 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #3 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 0x7f3fe9a05910 (LWP 29874)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f3ff0087513 in ?? () from /usr/lib64/libxine.so.1 #2 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #3 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 0x7f3fe7919910 (LWP 29876)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f400213253b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4 #2 0x00007f3ffdc29ab6 in ?? () from /usr/lib64/libthreadweaver.so.4 #3 0x00007f3ffdc2bbeb in ?? () from /usr/lib64/libthreadweaver.so.4 #4 0x00007f3ffdc2a1ef in ?? () from /usr/lib64/libthreadweaver.so.4 #5 0x00007f3ffdc2a648 in ThreadWeaver::Thread::run() () from /usr/lib64/libthreadweaver.so.4 #6 0x00007f4002131485 in ?? () from /usr/lib64/libQtCore.so.4 #7 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #8 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () Thread 4 (Thread 0x7f3fe0a85910 (LWP 29877)): [KCrash Handler] #5 0x00007f40021717f3 in QString::operator==(QString const&) const () from /usr/lib64/libQtCore.so.4 #6 0x00007f40026316f5 in KMimeType::is(QString const&) const () from /usr/lib64/libkdecore.so.5 #7 0x00007f3fe5a57ba8 in Meta::UmsHandler::addPath (this=0x1c17220, path=...) at /home/gwb/kde/src/amarok/src/collection/umscollection/handler/UmsHandler.cpp:410 #8 0x00007f3fe5a5a83b in Meta::UmsHandler::prepareToParseTracks (this=0x1c17220) at /home/gwb/kde/src/amarok/src/collection/umscollection/handler/UmsHandler.cpp:860 #9 0x00007f3fe5a61bc9 in Handler::UmsReadCapability::prepareToParseTracks (this=0x7f3fd000b220) at /home/gwb/kde/src/amarok/src/collection/umscollection/handler/capabilities/UmsReadCapability.cpp:31 #10 0x00007f4002d29b1e in Meta::MediaDeviceHandler::privateParseTracks (this=0x1c17220) at /home/gwb/kde/src/amarok/src/collection/mediadevicecollection/handler/MediaDeviceHandler.cpp:832 #11 0x00007f4002d2c42c in Meta::ParseWorkerThread::run (this=0x1bb8660) at /home/gwb/kde/src/amarok/src/collection/mediadevicecollection/handler/MediaDeviceHandler.cpp:1277 #12 0x00007f3ffdc2aeed in ?? () from /usr/lib64/libthreadweaver.so.4 #13 0x00007f3ffdc2b1ee in ThreadWeaver::Job::execute(ThreadWeaver::Thread*) () from /usr/lib64/libthreadweaver.so.4 #14 0x00007f3ffdc2a1bf in ?? () from /usr/lib64/libthreadweaver.so.4 #15 0x00007f3ffdc2a648 in ThreadWeaver::Thread::run() () from /usr/lib64/libthreadweaver.so.4 #16 0x00007f4002131485 in ?? () from /usr/lib64/libQtCore.so.4 #17 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #18 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #19 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f3fd9725910 (LWP 29878)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f400213253b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4 #2 0x00007f3ffdc29ab6 in ?? () from /usr/lib64/libthreadweaver.so.4 #3 0x00007f3ffdc2bbeb in ?? () from /usr/lib64/libthreadweaver.so.4 #4 0x00007f3ffdc2bc04 in ?? () from /usr/lib64/libthreadweaver.so.4 #5 0x00007f3ffdc2bc04 in ?? () from /usr/lib64/libthreadweaver.so.4 #6 0x00007f3ffdc2a1ef in ?? () from /usr/lib64/libthreadweaver.so.4 #7 0x00007f3ffdc2a648 in ThreadWeaver::Thread::run() () from /usr/lib64/libthreadweaver.so.4 #8 0x00007f4002131485 in ?? () from /usr/lib64/libQtCore.so.4 #9 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #10 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f3fd8f24910 (LWP 29879)): #0 0x00007f400085b049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f400213253b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4 #2 0x00007f3ffdc29ab6 in ?? () from /usr/lib64/libthreadweaver.so.4 #3 0x00007f3ffdc2bbeb in ?? () from /usr/lib64/libthreadweaver.so.4 #4 0x00007f3ffdc2a1ef in ?? () from /usr/lib64/libthreadweaver.so.4 #5 0x00007f3ffdc2a648 in ThreadWeaver::Thread::run() () from /usr/lib64/libthreadweaver.so.4 #6 0x00007f4002131485 in ?? () from /usr/lib64/libQtCore.so.4 #7 0x00007f400085665d in start_thread () from /lib64/libpthread.so.0 #8 0x00007f4000d94e1d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f4003c247a0 (LWP 29865)): #0 0x00007f400085b2cd in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f4002130f15 in ?? () from /usr/lib64/libQtCore.so.4 #2 0x00007f4002131080 in QThread::msleep(unsigned long) () from /usr/lib64/libQtCore.so.4 #3 0x00007f3ff02ec092 in ?? () from /usr/lib64/kde4/plugins/phonon_backend/phonon_xine.so #4 0x00007f3ffe52d1cf in ?? () from /usr/lib64/libphonon.so.4 #5 0x00007f4000cf9065 in ?? () from /lib64/libc.so.6 #6 0x00007f4000cf90b5 in exit () from /lib64/libc.so.6 #7 0x00007f400173d628 in ?? () from /usr/lib64/libQtGui.so.4 #8 0x00007f40037749f8 in KApplication::xioErrhandler(_XDisplay*) () from /usr/lib64/libkdeui.so.5 #9 0x00007f40001352be in _XIOError () from /usr/lib64/libX11.so.6 #10 0x00007f400013cc95 in ?? () from /usr/lib64/libX11.so.6 #11 0x00007f400013d547 in _XEventsQueued () from /usr/lib64/libX11.so.6 #12 0x00007f400012624b in XEventsQueued () from /usr/lib64/libX11.so.6 #13 0x00007f40017754dc in ?? () from /usr/lib64/libQtGui.so.4 #14 0x00007f3ffa388cca in g_main_context_check () from /usr/lib64/libglib-2.0.so.0 #15 0x00007f3ffa3894b0 in ?? () from /usr/lib64/libglib-2.0.so.0 #16 0x00007f3ffa3898e0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #17 0x00007f400223f3a3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #18 0x00007f400177531e in ?? () from /usr/lib64/libQtGui.so.4 #19 0x00007f4002215712 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #20 0x00007f4002215ae4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #21 0x00007f4002217c99 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #22 0x000000000040aeb2 in main (argc=2, argv=0x7fff45ad4308) at /home/gwb/kde/src/amarok/src/main.cpp:237 Reported using DrKonqi
Created attachment 42244 [details] STDERR from amarok --debug
What do you mean by "close button"? Eject perhaps? And is that inside of amarok or in the connected device applet on plasma-desktop?
On Sunday 28 March 2010 07:41:08 am Bart Cerneels wrote: > https://bugs.kde.org/show_bug.cgi?id=232051 > > > Bart Cerneels <bart.cerneels@kde.org> changed: > > What |Removed |Added > --------------------------------------------------------------------------- > - Status|UNCONFIRMED |NEEDSINFO > CC| |bart.cerneels@kde.org > Resolution| |WAITINGFORINFO > > > > > --- Comment #2 from Bart Cerneels <bart cerneels kde org> 2010-03-28 > 13:40:15 --- What do you mean by "close button"? Eject perhaps? And is > that inside of amarok or in the connected device applet on plasma-desktop? > I guess I mean the eject button - the one that shows up when you mouse over the collection header in the 'Local Sources' list. I usually hit this one >before< I use the desktop one to flush/unmount the device.
Please reopen NEEDSINFO bugs as soon as you have supplied the needed information.
*** Bug 237582 has been marked as a duplicate of this bug. ***
*** Bug 238845 has been marked as a duplicate of this bug. ***
*** Bug 244230 has been marked as a duplicate of this bug. ***
Confirmed by duplicates.
*** Bug 251627 has been marked as a duplicate of this bug. ***
*** Bug 256656 has been marked as a duplicate of this bug. ***
Can somebody reproduce this with Amarok 2.4 beta or 2.4-git? It doesn't crash here at all, using current git version (could also be related to bug 259849 in my case)
*** Bug 259878 has been marked as a duplicate of this bug. ***
Still broken. Stacktrace attached to #259878
The backtrace changed: Thread 3 (Thread 0x7f8bad4de710 (LWP 12702)): [KCrash Handler] #6 d_func (obj=0x1) at ../../src/corelib/kernel/qobject.h:125 #7 get (obj=0x1) at ../../src/corelib/kernel/qobject_p.h:174 #8 QtSharedPointer::ExternalRefCountData::getAndRef (obj=0x1) at tools/qsharedpointer.cpp:1252 #9 0x00007f8be6aacb77 in QWeakPointer<Collections::MediaDeviceCollection>::QWeakPointer<Collections::MediaDeviceCollection> (this=0x7f8ba8227398, ptr=0x1) at /usr/include/QtCore/qsharedpointer_impl.h:561 #10 0x00007f8be6aa5f3b in Meta::MediaDeviceTrack::MediaDeviceTrack (this=0x7f8ba8227380, collection=0x1) at /home/gwb/kde/src/amarok/src/core-impl/collections/mediadevicecollection/MediaDeviceMeta.cpp:110 #11 0x00007f8be6ab7948 in Meta::MediaDeviceHandler::privateParseTracks (this=0x1c4a340) at /home/gwb/kde/src/amarok/src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.cpp:865 #12 0x00007f8be6ab9da6 in Meta::ParseWorkerThread::run (this=0xefd9a0) at /home/gwb/kde/src/amarok/src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.cpp:1304 #13 0x00007f8be2323d75 in ?? () from /usr/lib64/libthreadweaver.so.4 #14 0x00007f8be2323eae in ThreadWeaver::Job::execute(ThreadWeaver::Thread*) () from /usr/lib64/libthreadweaver.so.4 #15 0x00007f8be23237bf in ?? () from /usr/lib64/libthreadweaver.so.4 #16 0x00007f8be2323878 in ThreadWeaver::Thread::run() () from /usr/lib64/libthreadweaver.so.4 #17 0x00007f8be5eedbf5 in QThreadPrivate::start (arg=0x11423c0) at thread/qthread_unix.cpp:248 #18 0x00007f8bd9cbca33 in ?? () from /usr/X11R6/lib64/libGL.so.1 #19 0x00007f8be2ea9a4f in start_thread () from /lib64/libpthread.so.0 #20 0x00007f8be4a5682d in clone () from /lib64/libc.so.6 #21 0x0000000000000000 in ?? ()
*** Bug 265301 has been marked as a duplicate of this bug. ***
On my up-to-date 2.4 GIT version, the bug is still open. It happens when I eject a media with "use in collection" uncheck and until the media is not completely scan (tracks appear in the browser).
*** Bug 265436 has been marked as a duplicate of this bug. ***
*** Bug 266464 has been marked as a duplicate of this bug. ***
*** Bug 269164 has been marked as a duplicate of this bug. ***
*** Bug 272139 has been marked as a duplicate of this bug. ***
Created attachment 59755 [details] New crash information added by DrKonqi amarok (2.4.0) on KDE Platform 4.6.2 (4.6.2) using Qt 4.7.2 - What I was doing when the application crashed: Un-plugged my portable media player before Amarok finished scanning files on it (i.e. un-plugged a few seconds after it was plugged in). -- Backtrace (Reduced): #6 operator QtSharedPointer::ExternalRefCountData* (obj=0x2f5b7d0) at ../../src/corelib/thread/qbasicatomic.h:169 #7 QtSharedPointer::ExternalRefCountData::getAndRef (obj=0x2f5b7d0) at tools/qsharedpointer.cpp:1255 #8 0x0000003ce50505d5 in QWeakPointer<Collections::MediaDeviceCollection> (this=<value optimized out>, collection=0x2f5b7d0) at /usr/include/QtCore/qsharedpointer_impl.h:565 #9 Meta::MediaDeviceTrack::MediaDeviceTrack (this=<value optimized out>, collection=0x2f5b7d0) at /usr/src/debug/amarok-2.4.0/src/core-impl/collections/mediadevicecollection/MediaDeviceMeta.cpp:110 #10 0x0000003ce5061698 in Meta::MediaDeviceHandler::privateParseTracks (this=0x2f56d20) at /usr/src/debug/amarok-2.4.0/src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.cpp:864
I have looked into it a bit and there are different places where the crash happens although one is far more common. I attach a patch with a preliminary fix. From experience it now crashes 20% of the time when unplugging once scanning. There might be a drawback to the patch as Amarok crashed once when unpluggin the device long after it had been scanned.
Created attachment 59888 [details] Patch partially fixing the problem
Matthieu, thank you for your patch, but please submit it to review board, the same way you did with your last one. Patches need to be submitted that way, not in a bug report.
Fixed with dd18d6cbfbfaa4f5369e578a75fe10ca3b353f3e
I would not close the bug quite yet. As I explained it fixes most of the crashes but there are still some remaining although harder to fix as they happen less often.
Ok, Open until further notice
*** Bug 274647 has been marked as a duplicate of this bug. ***
*** Bug 275429 has been marked as a duplicate of this bug. ***
*** Bug 277802 has been marked as a duplicate of this bug. ***
We have a similar problem with the Sanza Fuze bug 275918. The USB device is removed while the scanning is still in progress. As the scanner cannot be aborted and the USB collection does have no say in being deleted there is currently no way to fix those problems fast.
*** Bug 255082 has been marked as a duplicate of this bug. ***
*** Bug 278402 has been marked as a duplicate of this bug. ***
*** Bug 273454 has been marked as a duplicate of this bug. ***
Created attachment 62961 [details] New crash information added by DrKonqi amarok (2.4.0) on KDE Platform 4.6.00 (4.6.0) "release 6" using Qt 4.7.1 - What I was doing when the application crashed: I was ejecting the removable USB drive using the mini eject icon within Amarok before Amarok had finished scanning the device for mp3s. This crash behavior is repeatable. If you click eject after the mp3s are scanned it doesn't crash but clicking it while it's, presumedly, scanning will cause a crash. -- Backtrace (Reduced): #6 0x00007f25ae7972d3 in QString::operator== (this=0x7f25735be680, other=...) at tools/qstring.cpp:2139 #7 0x00007f25aed03bb5 in KMimeType::is (this=<value optimized out>, mimeTypeName=...) at /usr/src/debug/kdelibs-4.6.0/kdecore/services/kmimetype.cpp:518 #8 0x00007f25827f723c in Meta::UmsHandler::addPath (this=0x1fd7d80, path=<value optimized out>) at /usr/src/debug/amarok-2.4.0/src/core-impl/collections/umscollection/handler/UmsHandler.cpp:406 #9 0x00007f25827f759a in Meta::UmsHandler::prepareToParseTracks (this=0x1fd7d80) at /usr/src/debug/amarok-2.4.0/src/core-impl/collections/umscollection/handler/UmsHandler.cpp:844 #10 0x00007f25af472629 in Meta::MediaDeviceHandler::privateParseTracks (this=0x1fd7d80) at /usr/src/debug/amarok-2.4.0/src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.cpp:858
*** Bug 281481 has been marked as a duplicate of this bug. ***
Git commit 67aa4d8811773bff9739761b04a5ce1f94006350 by Bart Cerneels. Committed on 06/11/2011 at 08:58. Pushed by shanachie into branch 'master'. Add Changelog about new UMS plugin. Fixes a lot of crashes and wishes. BUG: 232051 BUG: 279966 BUG: 212617 BUG: 209161 FIXED-IN: 2.5 M +1 -0 ChangeLog http://commits.kde.org/amarok/67aa4d8811773bff9739761b04a5ce1f94006350
*** Bug 287123 has been marked as a duplicate of this bug. ***
*** Bug 295797 has been marked as a duplicate of this bug. ***