which engine do you use?
does it lock up?
does it crash?

how to reproduce?

x86 or x86_64 ?

The configuration I use is unchanged from my 10.0 environment:

- xine-internal
- GUI locks up
- no segfault so far, music keeps playing (will continue testing)
- problem appears intermittently (will continue testing)
- arch x86

I just happened again.

I had one song in my play list. I was switching views in the play list to the "lyrics" view. The lyrics for that song were not available (don't know if that is relevant).

A attached gdb gave me that backtrace:

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb696ad11 in ___newselect_nocancel () from /lib/libc.so.6
#2  0xb65ddf93 in XProcessInternalConnection () from /usr/X11R6/lib/libX11.so.6
#3  0xb65de32f in _XRead () from /usr/X11R6/lib/libX11.so.6
#4  0xb65dedd4 in _XReply () from /usr/X11R6/lib/libX11.so.6
#5  0xb65c6a1c in XGetImage () from /usr/X11R6/lib/libX11.so.6
#6  0xb6e2e5c6 in QPixmap::convertToImage () from /usr/lib/libqt-mt.so.3
#7  0xb748b12c in KWin::setIcons () from /opt/kde3/lib/libkdecore.so.4
#8  0xb7716a8d in KSystemTray::setPixmap () from /opt/kde3/lib/libkdeui.so.4
#9  0x08211eb8 in QValueListPrivate<KNetwork::KResolverEntry>::at ()
#10 0x08211ff1 in QValueListPrivate<KNetwork::KResolverEntry>::at ()
#11 0x082122ba in QValueListPrivate<KNetwork::KResolverEntry>::at ()
#12 0x0813b98d in QMapPrivate<QString, bool>::clear ()
#13 0x081353c1 in EngineController::staticMetaObject ()
#14 0x0813a33e in EngineController::staticMetaObject ()
#15 0xb6ed2b5d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#16 0xb6ed37bd in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#17 0xb720bec9 in QTimer::timeout () from /usr/lib/libqt-mt.so.3
#18 0xb6ef639f in QTimer::event () from /usr/lib/libqt-mt.so.3
#19 0xb6e73c47 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#20 0xb6e74a11 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#21 0xb75488e3 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#22 0xb6e68dd5 in QEventLoop::activateTimers () from /usr/lib/libqt-mt.so.3
#23 0xb6e23710 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---
#24 0xb6e8aa78 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#25 0xb6e8a90e in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#26 0xb6e737ff in QApplication::exec () from /usr/lib/libqt-mt.so.3
#27 0x08243b1c in TrackPickerDialogBase::staticMetaObject ()
#28 0xb68c987c in __libc_start_main () from /lib/libc.so.6
#29 0x0808e721 in ?? ()


(I hope I attached to the right thread)

That was the PID the KDE popup told me did not respond any more.

Experienced the same during playback (dynamic mode, but it tends to happen even with regular playlists, my collection is on NFS, but the NFS server itself is fine and music continues the play - just the GUI freezes).

When I attached strace to the hanging amarokapp process, was:

strace -p 18780
Process 18780 attached - interrupt to quit
futex(0x83c2784, FUTEX_WAIT, 2, NULL
 <unfinished ...>

Which then reminded me that I had seen something like this before: bug 193098

But, I'm already running the glibc with the fix. Sigh. It would have been nice ;-)

So, what kind of data should I try to gather for this issue?

This is the same as 115612.  It's just the usual case of a thread crashing inside malloc, then fork hanging in malloc in another thread.  Amarok is just not thread safe in many areas.

*** This bug has been marked as a duplicate of bug 115612 ***

Andreas, I'm not sure it's the same bug. This issue reported here, despite the subject, is not a crash with core, but an intermittent freeze.