| Summary: | Amarok randomly crashes (segfault) when playing music [@ SqlRegistry::emptyCache] | ||
|---|---|---|---|
| Product: | [Applications] amarok | Reporter: | Mirco <mirco.bugs> |
| Component: | Collections/Local | Assignee: | Amarok Bugs <amarok-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | arm4design, farl.rmz, fastsimplmail, giggi1999, l.jirkovsky, mail, matej, nick, ralf-engels, roger |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 2.8.0 | ||
| Target Milestone: | 2.9 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/amarok/3073b4f8403ff5268354f53011b4d57c684c4499 | Version Fixed/Implemented In: | 2.9 |
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Mirco
2013-12-19 16:49:47 UTC
Very strange crash, did you set up an external database instead of using the embedded one? Also: you say it is random, are you sure it is always the same reason, e.g are the backtraces identical? (In reply to comment #1) > Very strange crash, did you set up an external database instead of using the > embedded one? > > Also: you say it is random, are you sure it is always the same reason, e.g > are the backtraces identical? No, I'm using the embedded database just as preconfigured. Random means that the crash occurs after having played two songs, the next time it crashes after the fifth song, then again after the third, and so on... I don't know whether the backtraces are identical or not, sorry. I'm not used to read backtraces. (It's the second time for me reporting a bug.) But the circumstances are always the same: start playing a track in amarok, moving away from my computer (btw. screensavers are deactivated on my computer), then after a random couple of played songs amarok crashes. After the crash, parts of my desktop environment don't respond anymore, so I have to kill the whole KDE session and log in again to get back to normal behaviour. Does it crash on track change? In that case it might be worth trying to change the phonon backend. No, It didn't chrash on track change. Most of the time it crashed a few seconds after a track change. I will try another phonon backend (vlc?). At the moment, I'm using the gstreamer backend. *** Bug 329043 has been marked as a duplicate of this bug. *** Thank you for the feedback. The backtrace is extremely mysterious to me, it shouldn't have crashed at that point. Perhaps we can try to rule-out database corruption, please: 1. quit Amarok 2. backup (rename, don't delete) the ~/.kde/share/apps/amarok/mysqle directory (it may be .kde4 in some distros) 3. Start Amarok again, give it some time to rescan your collection 4. See whether you still get this behaviour, report back Yes, I definitely think we can rule-out database corruption. Now, after beeing a few days away from home (holidays), I booted my computer and installed all new updates (there were many gstreamer package updates as always from the packman repo), I'm not able to reproduce the crash anymore. Maybe the gstreamer plugins could've been the problem? I don't know. At this point, the only thing I did besides updating was to switch phonon backend to vlc and then back to gstreamer. So at the moment Amarok plays as flawless as ever without any crash so far. The only misbehaviour left now is the lag of the whole GUI (Amarok and also KDE) after starting a track (as mentioned before). Okay then. Wrt the lag: if it bothers you, you may report it as another bug. For any UI freezes, the most important piece of info is the backtrace of the lag, please do the following: Repeatedly (e.g. 3 times): 1. open console and paste (don't execute yet) the following command: gdb --ex "set height 0" --ex "bt 10" --ex detach --ex q -p $(pidof amarok) 2. start Amarok from desktop and execute the above command during the moment it lags Then paste all the backtraces inline to the bug. *** Bug 329981 has been marked as a duplicate of this bug. *** *** Bug 330825 has been marked as a duplicate of this bug. *** *** Bug 331675 has been marked as a duplicate of this bug. *** Created attachment 87057 [details]
New crash information added by DrKonqi
amarok (2.8.0) on KDE Platform 4.10.5 using Qt 4.8.5
- What I was doing when the application crashed:
updating music library
then play a track and after a few seconds of playback amarok segfaulted
-- Backtrace (Reduced):
#5 0x00007fca51e5487f in SqlRegistry::emptyCache() () from /usr/lib64/libamarok-sqlcollection.so.1
[...]
#7 0x00007fca702e4961 in QObject::event(QEvent*) () from /usr/lib64/qt/lib/libQtCore.so.4
#8 0x00007fca70d0cc5c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt/lib/libQtGui.so.4
#9 0x00007fca70d13220 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt/lib/libQtGui.so.4
#10 0x00007fca728c73aa in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5
*** Bug 343167 has been marked as a duplicate of this bug. *** Hi there: I came over from bug 343167, my backtrace is there. A bit of additional info: I'm using the VLC backend in phonon. Same as Mirco, I switch tracks, it plays a few seconds then crashes. I also have UI freezes (I'll try the above command) A weird quirk: I can not reproduce the crash running Amarok under gdb My local collection is also on a Samba share. Is that a bad idea? I like having it available anywhere on mynetwork. (In reply to Nick W from comment #15) > Hi there: > > I came over from bug 343167, my backtrace is there. > > A bit of additional info: > I'm using the VLC backend in phonon. > Same as Mirco, I switch tracks, it plays a few seconds then crashes. > I also have UI freezes (I'll try the above command) > > A weird quirk: > I can not reproduce the crash running Amarok under gdb > > My local collection is also on a Samba share. Is that a bad idea? I like > having it available anywhere on mynetwork. No, a samba share should just work fine, provided it is mounted and available when you try to play something. Maybe check if you do not have a timeout over the samba share. For me this works fine with both backends. FWIW: if you can't reproduce this when running with gdb I fear there is little we can do about, a crash needs to be reproducible every time. I have seen a freeze because of a recursive lock at the same location. I thought I solved it with 3073b4f8403ff5268354f53011b4d57c684c4499 add commit link *** Bug 346241 has been marked as a duplicate of this bug. *** *** Bug 348919 has been marked as a duplicate of this bug. *** *** Bug 384239 has been marked as a duplicate of this bug. *** |