Amarok crashes with phonon-vlc backend

Application: amarok (2.3-GIT)
KDE Platform Version: 4.4.81 (KDE 4.4.81 (KDE 4.5 >= 20100527)) "release 3"
Qt Version: 4.6.3
Operating System: Linux 2.6.33-zen2 i686
Distribution: "openSUSE 11.2 (i586)"

-- Information about the crash:
- What I was doing when the application crashed:
When using phonon-vlc backend, amarok crashes at every shutdown.
Switching to xine fixes the problem.

The crash can be reproduced every time.

-- Backtrace:
Application: Amarok (amarok), signal: Segmentation fault
[Current thread is 1 (Thread 0xb0f74720 (LWP 32764))]

Thread 7 (Thread 0xaac66b70 (LWP 300)):
#0 0xb7706424 in __kernel_vsyscall ()
#1 0xb5433d95 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122
#2 0xb57e827c in pthread_cond_wait () from /lib/libc.so.6
#3 0xae896bb3 in vlc_cond_wait () from /usr/lib/libvlccore.so.5
#4 0x0a26a51c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 6 (Thread 0xa950cb70 (LWP 306)):
#0 0xb7706424 in __kernel_vsyscall ()
#1 0xb5433d95 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122
#2 0xb57e827c in pthread_cond_wait () from /lib/libc.so.6
#3 0xb645b730 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#4 0xb4efe94a in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0xab49ad8, th=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/WeaverImpl.cpp:365
#5 0xb4f0126b in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0xab00140, th=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/WorkingHardState.cpp:80
#6 0xb4efce0a in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0xab49ad8, th=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/WeaverImpl.cpp:356
#7 0xb4f0136c in ThreadWeaver::WorkingHardState::applyForWork (this=0xab00140, th=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/WorkingHardState.cpp:71
#8 0xb4efebe3 in ThreadWeaver::WeaverImpl::applyForWork (this=0xab49ad8, th=0xab49158, previous=0xb92eac8) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/WeaverImpl.cpp:351
#9 0xb4eff294 in ThreadWeaver::ThreadRunHelper::run (this=0xa950c304, parent=0xab49ad8, th=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/Thread.cpp:87
#10 0xb4eff90a in ThreadWeaver::Thread::run (this=0xab49158) at /usr/src/debug/kdelibs-4.4.81svn1131245/threadweaver/Weaver/Thread.cpp:142
#11 0xb645a62f in ?? () from /usr/lib/libQtCore.so.4
#12 0xb542f6e5 in start_thread (arg=0x0) at pthread_create.c:297
#13 0xb542f600 in ?? () at pthread_create.c:216 from /lib/libpthread.so.0

Thread 5 (Thread 0xa8d0bb70 (LWP 307)):
#0 0xb7706424 in __kernel_vsyscall ()
#1 0xb5433d95 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122
#2 0xb57e827c in pthread_cond_wait () from /lib/libc.so.6
#3 0xb645b730 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#4 0xb4efe94a in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssi...

The backtrace doesn't show any relation to the Phonon backend, though.

*** Bug 240035 has been marked as a duplicate of this bug. ***

*** Bug 240236 has been marked as a duplicate of this bug. ***

*** Bug 240543 has been marked as a duplicate of this bug. ***

*** Bug 241076 has been marked as a duplicate of this bug. ***

Created attachment 47849
New crash information added by DrKonqi

amarok (2.3-GIT) on KDE Platform 4.4.85 (KDE 4.4.85 (KDE 4.5 Beta2)) using Qt 4.7.0

- What I was doing when the application crashed: Closed Amarok after playing a track. Fresh, clean build of Amarok, VLC, and phonon-VLC.

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
#7 0x00007f0018bd30b7 in XrmDestroyDatabase (db=0x1e30b70) at ../../src/Xrm.c:2642
#8 0x00007f0018bbd95d in _XFreeDisplayStructure (dpy=0x1e3d1c0) at ../../src/OpenDis.c:839
#9 0x00007f0018ba8e7f in XCloseDisplay (dpy=0x1e3d1c0) at ../../src/ClDisplay.c:82
#10 0x00007f001a9a4635 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

Changing to confirmed.

Created attachment 48239
New crash information added by DrKonqi

amarok (2.3-GIT) on KDE Platform 4.4.86 (KDE 4.4.86 (KDE 4.5 >= 20100616)) "release 3" using Qt 4.6.3

- What I was doing when the application crashed: I closed Amarok using the icon in the Systemtray and got a bugreport saying that Amarok crashed.

-- Backtrace (Reduced):
#7 0x00007f83fc9b9a27 in XrmDestroyDatabase (db=0x7bfbf0) at Xrm.c:2642
#8 0x00007f83fc9a1dbd in _XFreeDisplayStructure (dpy=0x7af7e0) at OpenDis.c:839
#9 0x00007f83fc98d08f in XCloseDisplay (dpy=0x7af7e0) at ClDisplay.c:82
#10 0x00007f83fdde283d in qt_cleanup () at kernel/qapplication_x11.cpp:2635
#11 0x00007f83fdd6f670 in QApplication::~QApplication (this=0x7fff35847cc0, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1086

Please always paste backtraces inline, attachements are not searchable.

Thread 1 (Thread 0x7f840034f7a0 (LWP 10139)):
[KCrash Handler]
#6 0x00007f83fb84f084 in pthread_mutex_lock () from /lib64/libpthread.so.0
#7 0x00007f83fc9b9a27 in XrmDestroyDatabase (db=0x7bfbf0) at Xrm.c:2642
#8 0x00007f83fc9a1dbd in _XFreeDisplayStructure (dpy=0x7af7e0) at OpenDis.c:839
#9 0x00007f83fc98d08f in XCloseDisplay (dpy=0x7af7e0) at ClDisplay.c:82
#10 0x00007f83fdde283d in qt_cleanup () at kernel/qapplication_x11.cpp:2635
#11 0x00007f83fdd6f670 in QApplication::~QApplication (this=0x7fff35847cc0, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1086
#12 0x00007f83ff67f20b in App::~App (this=0x7fff35847cc0, __in_chrg=<value optimized out>) at /home/zoehneto/amarok/src/App.cpp:212
#13 0x00000000004073b6 in main (argc=1, argv=0x7fff35849c28) at /home/zoehneto/amarok/src/main.cpp:235

Possible duplicates by query: bug 241076, bug 240543, bug 240236, bug 240035, bug 240001.

Reported using DrKonqi

Created attachment 48405
New crash information added by DrKonqi

amarok (2.3-GIT) on KDE Platform 4.4.90 (KDE 4.4.90 (KDE 4.5 RC1)) using Qt 4.7.0

- What I was doing when the application crashed:

Every time I close the program it crashes. Same thing happens with Bangarang compiled from sources.

-- Backtrace (Reduced):
#7 0x00007f9f632a20b7 in XrmDestroyDatabase (db=0x23c8160) at ../../src/Xrm.c:2642
#8 0x00007f9f6328c95d in _XFreeDisplayStructure (dpy=0x23dc4e0) at ../../src/OpenDis.c:839
#9 0x00007f9f63277e7f in XCloseDisplay (dpy=0x23dc4e0) at ../../src/ClDisplay.c:82
#10 0x00007f9f65073635 in qt_cleanup () at kernel/qapplication_x11.cpp:2638
#11 0x00007f9f650043a7 in ~QApplication (this=0x7fff15e16560, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1110

Created attachment 49590
New crash information added by DrKonqi

amarok (2.3.1) on KDE Platform 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2)) using Qt 4.7.0

- What I was doing when the application crashed:
Closed amarok after playing a track.
Closed amarok while playing a track.
All these trigger a crash.

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
#7 0x00007ffd66877117 in XrmDestroyDatabase (db=0xef58e0) at ../../src/Xrm.c:2640
#8 0x00007ffd668619ed in _XFreeDisplayStructure (dpy=0xee90a0) at ../../src/OpenDis.c:837
#9 0x00007ffd6684ceaf in XCloseDisplay (dpy=0xee90a0) at ../../src/ClDisplay.c:80
#10 0x00007ffd6861cd05 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

Created attachment 49847
New crash information added by DrKonqi

amarok (2.3.1) on KDE Platform 4.5.00 (KDE 4.5.0) using Qt 4.7.0

- What I was doing when the application crashed:

When using phonon-vlc backend, amarok crashes at every shutdown.

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
#7 0x00007f3c7ad65117 in XrmDestroyDatabase (db=0x103f680) at ../../src/Xrm.c:2640
#8 0x00007f3c7ad4f9ed in _XFreeDisplayStructure (dpy=0x1065c40) at ../../src/OpenDis.c:837
#9 0x00007f3c7ad3aeaf in XCloseDisplay (dpy=0x1065c40) at ../../src/ClDisplay.c:80
#10 0x00007f3c7cb0ad05 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

Sure the Status of this bug is not "new", it is "confirmed".

What do the developers think about these crashes, where is the bug, how can this be fixed?

I'm unable to reproduce it locally, and the backtraces don't really tell me much.

Does everyone who experience this use pulseaudio? I know pulseaudio does some trickery with the root X window, maybe that's confusing something?

Pulseaudio libs are in use here (checked with lsof), although I don't use pulseaudio.

(In reply to comment #13)
> Sure the Status of this bug is not "new", it is "confirmed".

"New" means confirmed, there is no such option as "Confirmed". An unconfirmed bug states "Unconfirmed"

(In reply to comment #14)
> I'm unable to reproduce it locally, and the backtraces don't really tell me
> much.
>
> Does everyone who experience this use pulseaudio? I know pulseaudio does some
> trickery with the root X window, maybe that's confusing something?

The same thing happened with and without pulseaudio. I would prefer the VLC backend, but xine doesn't crash now, and VLC does. Pulseaudio keeps the sound in flash working right, so I'm using it now.

(In reply to comment #14)
> I'm unable to reproduce it locally, and the backtraces don't really tell me
> much.
>
> Does everyone who experience this use pulseaudio? I know pulseaudio does some
> trickery with the root X window, maybe that's confusing something?

Pulseaudio libs are installed here but not used. Pulseaudio for me creates an unwanted latency / delay in apps, so it's disabled.

@Myriam Schweingruber: You are right, sorry, I was confused about another bug tracking system.

@Martin Sandsmark: I use PulseAudio and when closing an app that uses Phonon, the VLC backend crashes. This happens with KDE 4.4 and 4.5.

@Martin Sandsmark:

I have got this bug too (same kind of backtrace), and it seems to be related to pulse, as it does not crash anymore if I uninstall the plugin "vlc-plugin-pulse" in ubuntu.
But it seems to be related to phonon backend as the application VLC does not crash.

If the crash is related to PA then the following patch to PA should fix it.

http://pulseaudio.org/ticket/799

I've been using this patch for a while, so it's pretty stable. I'll probably push it into the stable queue for PA shortly to avoid these kind of issue.

It's also been in Mandriva Cooker since it reopened a month or so back and no problems reported.

Can someone look to see if this patch solves the problem? If needed I can create a testing package for PA on Mandriva 2010.1.

Col

(In reply to comment #20)
>...
> pulse, as it does not crash anymore if I uninstall the plugin
> "vlc-plugin-pulse" in ubuntu.
>....

Thanks to your comment I've resolved this issue. I'm on opensuse but removing "vlc-aout-pulse" resolved this type of crash.

Furthermore I've did some testing and:
- reinstalling above vlc pulse package will lead again to crashes
- installing xine pulse package (libxine1-pulse) will cause same crashes on exit even with xine engine

In both scenarios pulseaudio is not activated, just installed.

So it is not vlc backend related, but seems like pulseaudio is the root of problem here for sure.

(In reply to comment #22)
> In both scenarios pulseaudio is not activated, just installed.
>
> So it is not vlc backend related, but seems like pulseaudio is the root of
> problem here for sure.

That makes sense as in order for the pulseaudio client application to test to see whether a server is running, the PA client application must check PA's configuration directives to see where to try and connect.

In your case this will ultimately result in the "PA is not running" scenario, and carry about it's business, but to get that far the X11 libraries have to be loaded (as PA configuration can be stored in X11 properties of the root X window to allow for seamless SSHing to remote machines and running audio producing applications remotely, but still seeing and hearing your application locally).

I pretty strongly suspect that the patch I linked above would address this issue by using the thread-safe XCB in PA rather than Xlib.

Note that calling XlibInitThreads (or whatever the API call is really called!) prior to all this should also work around this issue but this is sometimes awkward to do in client applications when an abstraction layer like phoon+engine is used.

*** Bug 246444 has been marked as a duplicate of this bug. ***

In addition to the XCB patch for PA, it's probably also worth ensuring the XInitThreads call in VLC's modules/audio_output/pulse.c has been removed (it's not present in vlc 1.1.2 but not sure about earlier versions).

*** Bug 247987 has been marked as a duplicate of this bug. ***

Just for reference, my comment #25 is incorrect: The call is still there in 1.1.2 but I think it's wrapped up in a wrapper function... see my second to last comment on bug #247987 for a more verbose version of this comment :D

Continueing on from bug 247987: After commenting out the vlc_xlib_init() call in VLC's modules/audio_output/pulse.c and while still using Rex' patched PA test packages, the crashing disappears.

The thing is you say in comment #25 here that the call is not present in VLC 1.1.2, but I have VLC 1.1 from git (i.e. even newer than 1.1.2 now) and it's still there ...

NVM the last para, I skipped over comment #27.

The bottom line is that VLC upstream has to change its PA code, then?

I'm trying to see when we can do an official PA release so we can put make the xlib init call in vlc's pulse.c conditional on the library version. I'll update this bug when I know more.

*** Bug 250604 has been marked as a duplicate of this bug. ***

Created attachment 51768
New crash information added by DrKonqi

amarok (2.3.2) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0

- What I was doing when the application crashed:

Exited Amarok, and got message that it had crashed, decided to send bug report as I am using newest versions of KDE and Amarok.

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x44495f54) at pthread_mutex_lock.c:50
#7 0x000000350b649da7 in XrmDestroyDatabase (db=0x1761120) at Xrm.c:2642
#8 0x000000350b63476d in _XFreeDisplayStructure (dpy=0x17680e0) at OpenDis.c:839
#9 0x000000350b61fcbf in XCloseDisplay (dpy=0x17680e0) at ClDisplay.c:82
#10 0x000000345cc21ef5 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

1/ This bug is _not_ upstream. It is a bug in KDE's Phonon VLC, not in LibVLC.

2/ This bug is _not_ resolved. I had sent a patch for this and it was summarily reverted so obviously the problem is still there.

3/ It is not specific to PulseAudio and even with an up-to-date libpulse (i.e. >= 0.9.22), the problem can still show up. In particular, this bug will also show up if LibVLC renders video through GLX or SDL-X11.

Anyway, there are two ways to cleanly solve this crash:

* Call XInitThreads() from Amarok before creation of the QApplication object.
or
* Pass the "--no-xlib" parameter to libvlc_new() from Phonon VLC.

Created attachment 54202
New crash information added by DrKonqi

amarok (2.3.2) on KDE Platform 4.5.4 (KDE 4.5.4) "release 9" using Qt 4.6.3

After every close of Amarok using VLC-Backend , amarok crash and has some break while using amarok, music leg and come back sometimes!!

-- Backtrace (Reduced):
#7 0x00007fbb14651a27 in XrmDestroyDatabase (db=0x7a3c70) at Xrm.c:2642
#8 0x00007fbb14639dbd in _XFreeDisplayStructure (dpy=0x780140) at OpenDis.c:839
#9 0x00007fbb1462508f in XCloseDisplay (dpy=0x780140) at ClDisplay.c:82
#10 0x00007fbb15a7a83d in qt_cleanup () at kernel/qapplication_x11.cpp:2635
#11 0x00007fbb15a07670 in QApplication::~QApplication (this=0x7ffff4466f70, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1086

*** Bug 259206 has been marked as a duplicate of this bug. ***

Created attachment 54514
New crash information added by DrKonqi

amarok (2.3.90) on KDE Platform 4.5.85 (4.6 Beta2) using Qt 4.7.1

- What I was doing when the application crashed:

using phonon-vlc 0.3.1 on kubuntu natty (kde 4.6b2), amarok crashed on exit

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x620069006c0000) at pthread_mutex_lock.c:50
#7 0x00007f9375816eb7 in XrmDestroyDatabase (db=0x2377290) at ../../src/Xrm.c:2640
#8 0x00007f93757ff47d in _XFreeDisplayStructure (dpy=0x2350590) at ../../src/OpenDis.c:837
#9 0x00007f93757ea83f in XCloseDisplay (dpy=0x2350590) at ../../src/ClDisplay.c:80
#10 0x00007f937756286d in qt_cleanup () at kernel/qapplication_x11.cpp:2666

*** Bug 256010 has been marked as a duplicate of this bug. ***

So can we just have Phonon-VLC pass that --no-xlib parameter and be done with it? (VLC upstream clearly refuses to do that by default and I don't see any other solution in sight.)

Created attachment 56305
pass --no-xlib to libvlc_new()

patch implementing suggestion from comment #59 to pass --no-xlib to libvlc_new()

See:

commit fa898f1beef7fae7c58fc1284c50a4cb886ad109
Author: Mark Kretschmann <email address hidden>
Date: Fri Nov 12 07:03:46 2010 +0100

    Revert "Disable usage of Xlib"

    This reverts commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4.

    This revert was recommended by j-b, as the commit broke Phonon-VLC in many cases.
    (mine didn't work at all).

And:

commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4
Author: Rémi Denis-Courmont <email address hidden>
Date: Sat Oct 30 17:56:59 2010 +0300

    Disable usage of Xlib

    Close #240001

    VLC plugins call XInitThreads() before XOpenDisplay(). As per the
    Xlib documentation, this is required to use Xlib from more than one
    thread in a single process, which is to say any other thread besides
    the Qt main loop thread. Do note that, contrary to XLockDisplay(),
    XInitThreads() _must_ be called even if Display pointers are not
    shared across threads. In fact, XInitThreads() initialize locks around
    static data within Xlib.

    Unfortunately, XCloseDisplay() will crash if XInitThreads() is
    called for the first time only after XOpenDisplay(). By design,
    XInitThreads() must be called from main() before Qt or anything else
    uses Xlib. Phonon cannot force the main application to call
    XInitThreads(), and indeed none that I know do it correctly today.

    As an alternative, VLC provides an undocumented --no-xlib option. It
    blacklists all VLC plugins that call XInitThreads() because they are
    known to depend on Xlib. This is the only viable solution that does not
    involve changing libQtGUI, libX11 and/or all Phonon applications.

    Signed-off-by: Jean-Baptiste Kempf <email address hidden>

Unless the situation that caused Marky to revert that is resolved, then adding it back in again wont help....

> As an alternative, VLC provides an undocumented --no-xlib option. It
> blacklists all VLC plugins that call XInitThreads() because they are
> known to depend on Xlib.

Well, if the PulseAudio backend is one of those plugins, then that's clearly not an acceptable solution. The call to XInitThreads in VLC's PulseAudio plugin needs to be removed (it's not necessary with current PulseAudio) and --no-xlib must not blacklist the PulseAudio plugin.

(In reply to comment #67)
> > As an alternative, VLC provides an undocumented --no-xlib option. It
> > blacklists all VLC plugins that call XInitThreads() because they are
> > known to depend on Xlib.
>
> Well, if the PulseAudio backend is one of those plugins, then that's clearly
> not an acceptable solution. The call to XInitThreads in VLC's PulseAudio plugin
> needs to be removed (it's not necessary with current PulseAudio) and --no-xlib
> must not blacklist the PulseAudio plugin.

This is not a problem these days. It's been removed from VLC 1.1.6 when compiled with PA 0.9.22.

I've been patching this stuff for quite a while now in the Mandriva packages for Pulse+VLC and have helped the relevant maintainers in Fedora and Ubuntu to do the same.

Well, Fedora-targeted packages of VLC are in RPM Fusion, not Fedora, and the maintainer there refuses to apply the patch, see https://bugzilla.rpmfusion.org/show_bug.cgi?id=1403

Well there is not much you can do other than suggest to them that they should apply the patches or just wait until 1.1.6 which has the patch in there already. It will have to be compiled against PA 0.9.22 tho' (the upstream patch) or it will need to be tweaked accordingly if they know the PA 0.9.21 build has the XCB patches applied (that's why I do a brutal patch as I know the last stable distro release in Mandriva has the XCB patches applied in PA).

But IMO, this is not a reason to hold back in Phonon. All the necessary bits are out there. And when 1.1.6 of VLC is official then everything has both released versions and well known patches, so they maintainers can take their pick.

There are two relevant changes in LibVLC 1.1.6 (from 1.1.5):

1) Xlib is automatically disabled, as if --no-xlib were used when appropriate. This will cause a big warning on the standard error to shame the developers that ignore the --no-xlib flag.

2) If PulseAudio is .22 or later at BUILD TIME of VLC, the PulseAudio plugin won't use Xlib anymore.

As far as AmaroK does not do any video thing with Phonon/VLC, AmaroK should be "fixed" with the new PulseAudio and LibVLC. However, this bug will still affect video-capable Phonon-based applications. The following other LibVLC components are known to use Xlib:
 - video outputs: GLX, EGL, SDL, ASCII Art
 - decoders: libavcodec through VA-API
(- VLC graphical user interfaces)
Therefore, I think Phonon-VLC is still buggy considering that my --no-xlib fix was reverted,

@Rémi: While I totally agree with the principles, I guess it's possible that the Xlib modules in VLC are still needed (I'm not really sure if I'm honest - I remember it caused me problems locally while testing the --no-xlib argument, but I didn't test extensively).

If it's found that Phonon does still need those Xlib modules for the time being (while a better solution is worked on), which seems to have been the previous experience, is it possible to specifically enable Xlib with a --xlib or --enable-xlib option from 1.1.6+? I presume so, and the presence of either Xlib option will suppress the message on stderr?

Anyway, more testing needed for this I guess.

Created attachment 56362
New crash information added by DrKonqi

amarok (2.4.0) on KDE Platform 4.5.5 (KDE 4.5.5) using Qt 4.7.1

- What I was doing when the application crashed:
I was closing out Amarok when Amarok crashed.

-- Backtrace (Reduced):
#6 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
#7 0x00007f99b2e3e027 in XrmDestroyDatabase (db=0xa6bbb0) at Xrm.c:2640
#8 0x00007f99b2e2479d in _XFreeDisplayStructure (dpy=0xa745f0) at OpenDis.c:642
#9 0x00007f99b2e0fa5f in XCloseDisplay (dpy=0xa745f0) at ClDisplay.c:72
[...]
#11 0x00007f99b4b5bb61 in QApplication::~QApplication() () from /usr/lib/libQtGui.so.4

*** Bug 258333 has been marked as a duplicate of this bug. ***

I update vlc 1.1.6 today.
Problem seems solved.

Archlinux package version:
extra/phonon-vlc 0.3.2-1
extra/vlc 1.1.6-1
extra/libpulse 0.9.22-2
extra/pulseaudio 0.9.22-2

*** Bug 264705 has been marked as a duplicate of this bug. ***

*** Bug 263080 has been marked as a duplicate of this bug. ***

*** Bug 259969 has been marked as a duplicate of this bug. ***

*** Bug 252584 has been marked as a duplicate of this bug. ***

*** Bug 261914 has been marked as a duplicate of this bug. ***

AFAIU, newer AmaroK calls XInitThreads() at startup, so this bug should be fixed for good at last...

*** Bug 265805 has been marked as a duplicate of this bug. ***

*** Bug 266419 has been marked as a duplicate of this bug. ***

*** Bug 266583 has been marked as a duplicate of this bug. ***

*** Bug 266582 has been marked as a duplicate of this bug. ***

*** Bug 266763 has been marked as a duplicate of this bug. ***

*** Bug 267021 has been marked as a duplicate of this bug. ***

*** Bug 268404 has been marked as a duplicate of this bug. ***

Current git master is using --no-xlib again, please test it if you get a chance.

*** Bug 269935 has been marked as a duplicate of this bug. ***

*** Bug 265280 has been marked as a duplicate of this bug. ***

*** Bug 269954 has been marked as a duplicate of this bug. ***

*** Bug 270825 has been marked as a duplicate of this bug. ***

*** Bug 271049 has been marked as a duplicate of this bug. ***

*** Bug 271392 has been marked as a duplicate of this bug. ***

Re-introduced --no-xlib as per:
https://projects.kde.org/projects/kdesupport/phonon/phonon-vlc/repository/revisions/ee2677c8b959f54e4deb89cd9fd012a644e7ecd3

Fixed as per:
https://projects.kde.org/projects/kdesupport/phonon/phonon-vlc/repository/revisions/663b8a4dce8a7437fe5c3061884e282e784cbbc9

Reassigning to the new bugzilla product for better bug tracing of the various
backends. Sorry for the noise.

*** Bug 270828 has been marked as a duplicate of this bug. ***