Bug 240001

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 [details]
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 [details]
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 [details]
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 [details]
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 [details]
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 [details]
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

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

Created attachment 52114 [details]
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:
i used phonon-vlc backend to play audio files, and when i closed amarok, it crashed

-- Backtrace (Reduced):
#7  0x00007fb83888c767 in XrmDestroyDatabase (db=0x7cbde0) at Xrm.c:2640
#8  0x00007fb838872d9d in _XFreeDisplayStructure (dpy=0x7ddfa0) at OpenDis.c:642
#9  0x00007fb83885e04f in XCloseDisplay (dpy=0x7ddfa0) at ClDisplay.c:72
#10 0x00007fb83a5d9b2d in qt_cleanup () at kernel/qapplication_x11.cpp:2638
#11 0x00007fb83a5658d6 in QApplication::~QApplication (this=0x7fff61d88550, __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1121

FWIW, we do not need any more crash information and backtraces for this bug. It's been fixed in PA but we need to do a release so that conditional code can be triggered depending on whether or not this fix is available or not.

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

Created attachment 52563 [details]
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:
the fact of closing amarok in the main window or the notification area causes a segmentation fault

-- Backtrace (Reduced):
#6  __pthread_mutex_lock (mutex=0x2e98a0) at pthread_mutex_lock.c:50
#7  0x00007fd6bd152117 in XrmDestroyDatabase () from /usr/lib/libX11.so.6
#8  0x00007fd6bd13c9ed in _XFreeDisplayStructure () from /usr/lib/libX11.so.6
#9  0x00007fd6bd127eaf in XCloseDisplay () from /usr/lib/libX11.so.6
#10 0x00007fd6beefade5 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

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

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

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

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

Still no PA release?

Nope, not yet. Hopefully soon tho'.

Closing as upstream since this needs a fix in Pulseaudio

I wanted to add, that this crash occurs as long as vlc-plugin-pulse is still installed, even when pulseaudio (pulseaudio-module-x11 & pulseaudio) is removed completely from the system.

(In reply to comment #45)
> I wanted to add, that this crash occurs as long as vlc-plugin-pulse is still
> installed, even when pulseaudio (pulseaudio-module-x11 & pulseaudio) is removed
> completely from the system.

That is expected. The problem is not actually with the use of Xlib in the pulseaudio daemon itself, but rather in the libpulse client. This has now been completely removed and the patches are in the stable-queue tree of PulseAudio which we generally recommend distros to use. I certainly ship this version with my pacakges.

However, in order to address the problem fully, the call in VLC needs to be removed, but this can only really be done when it knows the relevant patch is included in libpulse. It can only do this with a version check (e.g. check at runtime the version of libpulse) otherwise other X11 related problems can come in too. Note that several other vlc libraries will also suffer similar issue but the libpulse one is likely the most noticeable one.

I'd recommend you ask your distro to ship PA from the stable-queue all the same tho' and then ship a patched VLC also until the proper checks can be added.

Created attachment 52806 [details]
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:
Playing a 96Khz/24bt flac file, when song was finished closed amarok and it crashed.
- Custom settings of the application:
Because the Xine backend won't play higher rez flac files (at least on my system.) I used the VLC backend.

-- Backtrace (Reduced):
#6  __pthread_mutex_lock (mutex=0x434c2f382d465455) at pthread_mutex_lock.c:50
#7  0x00007f1d94fc4117 in XrmDestroyDatabase () from /usr/lib/libX11.so.6
#8  0x00007f1d94fae9ed in _XFreeDisplayStructure () from /usr/lib/libX11.so.6
#9  0x00007f1d94f99eaf in XCloseDisplay () from /usr/lib/libX11.so.6
#10 0x00007f1d96d6cde5 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

I (not so) humbly believe this bug resolution is incorrect. The Phonon-VLC Xlib thread crash can occur with any VLC plugin that uses Xlib. PulseAudio is just one of them. But it also affects avcodec when using VAAPI, and the OpenGL output. In those two cases, we won't get away with patching "upstream" to not use Xlib.

As such, the correct generic solution should be one of these:
(1) The Phonon VLC backend passes the "--no-xlib" to libvlc_new(). This will ensure that LibVLC never calls XInitThreads in your back, and in fact never uses Xlib at all.
(2) All Phonon applications are fixed to call XInitThreads in main().

I would further note that this bug probably affects other Phonon backends than VLC, albeit in more subtle and difficult to reproduce manners. Basically, if you use Xlib from more than one thread,  you MUST call XInitThreads() first.

> In those two cases, we won't get away with patching "upstream" to not use Xlib.

Are you sure? Is there any technical reason those cannot migrate to XCB as well? Remember that Xlib is deprecated, XCB should be used instead.

(In reply to comment #49)
> > In those two cases, we won't get away with patching "upstream" to not use Xlib.
> 
> Are you sure? Is there any technical reason those cannot migrate to XCB as
> well? Remember that Xlib is deprecated, XCB should be used instead.

For OpenGL, moving away from Xlib is impossible:
http://xcb.freedesktop.org/opengl/
I haven't looked closely at VAAPI, but I suspect it's the same problem: the specification is an API that assumes Xlib.

So that leaves three options that I can think of:
(1) Make Xlib always thread-safe, turn XInitThreads into a no-op.
(2) Call XInitThreads before XOpenDisplay within libQtGui (this will break apps that call XOpenDisplay before they create the QApplication).
(3) Patch all Phonon applications to call XInitThreads from main.
None of that sounds too likely to me.

A solution which might work to implement (3) on ELF platforms is to link this snippet as a .c file into libphonon.so:
__attribute__((constructor)) void phonon_magic_constructor(void)
{
  XInitThreads();
}

(It might cause trouble due to race conditions with other constructor sections though, e.g. the constructors for global C++ objects.)


> For OpenGL, moving away from Xlib is impossible:
> http://xcb.freedesktop.org/opengl/

It's not impossible, it's just not implemented yet. The current API is tied to Xlib, but VLC's OpenGL backend could migrate to an XCB-based one once there is one. The problem is that there isn't any yet (assuming that that page is still up to date).

(In reply to comment #51)
> A solution which might work to implement (3) on ELF platforms is to link this
> snippet as a .c file into libphonon.so:
> __attribute__((constructor)) void phonon_magic_constructor(void)
> {
>   XInitThreads();
> }

That fails to address the possibility that phonon is dlopen()'d after the application has already started.

> > For OpenGL, moving away from Xlib is impossible:
> > http://xcb.freedesktop.org/opengl/
> 
> It's not impossible, it's just not implemented yet. The current API is tied
> to Xlib, but VLC's OpenGL backend could migrate to an XCB-based one once
> there is one. The problem is that there isn't any yet (assuming that that
> page is still up to date).

The API is part of the specification which you cannot just change unilateraly. And how would you force proprietary GLX implementations (think if ATI and NV here) to provide XCB variants? See also http://kesakoodi2k9.wordpress.com/2009/06/11/discoveries-about-xcb-xlib-glx-and-opengl/

> The API is part of the specification which you cannot just change unilateraly.

You write your own specification, referencing the OpenGL specification in a citation. Then apps which want to actually support threads properly will use the better specification instead of the original one.

> And how would you force proprietary GLX implementations (think if ATI and NV
> here) to provide XCB variants?

You just drop support for them (unless/until they adjust to the current APIs). Nouveau is getting advanced enough for this to be a serious proposition these days.

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

Created attachment 53616 [details]
New crash information added by DrKonqi

amarok (2.3.2) on KDE Platform 4.5.3 (KDE 4.5.3) 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  0x00007ff3ba281117 in XrmDestroyDatabase (db=0x24c4eb0) at ../../src/Xrm.c:2640
#8  0x00007ff3ba26b9ed in _XFreeDisplayStructure (dpy=0x24e6400) at ../../src/OpenDis.c:837
#9  0x00007ff3ba256eaf in XCloseDisplay (dpy=0x24e6400) at ../../src/ClDisplay.c:80
#10 0x00007ff3bc22ede5 in qt_cleanup () at kernel/qapplication_x11.cpp:2638

Sorry, here amarok crash with phonon-vlc event if i remove pulse audio vlc plugin :(

phonon-vlc 0.3.

(In reply to comment #56)
> Sorry, here amarok crash with phonon-vlc event if i remove pulse audio vlc
> plugin :(
> 
> phonon-vlc 0.3.

If you use pulseaudio, you could still be using PA client libraries via alsa-pulse plugin and thus still hitting an Xlib borkage of some kind.

I'd update to the latest version of pulseaudio (0.9.22) or ask your distro to include the relevant patches to ensure that PA does not use Xlib and thus avoids any issues related to it. Note that you will still want to patch the current (i.e. 1.1.5) vlc code to ensure it's module does not call XInitThreads. You can use this patch if you like:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/vlc/current/SOURCES/0101-pulse-Disable-xlib-in-pulse.-libpulse-now-uses-xcb-o.patch?revision=601141&view=markup

Created attachment 54037 [details]
New crash information added by DrKonqi

amarok (2.3.2) on KDE Platform 4.5.80 (4.6 Beta1) using Qt 4.7.1

- What I was doing when the application crashed:

using phonon-vlc 0.2 on kubuntu natty (kde 4.6b1), amarok crashed on exit

-- Backtrace (Reduced):
#6  __pthread_mutex_lock (mutex=0x620069006c0000) at pthread_mutex_lock.c:50
#7  0x00007f377caceeb7 in XrmDestroyDatabase (db=0x15d3e80) at ../../src/Xrm.c:2640
#8  0x00007f377cab747d in _XFreeDisplayStructure (dpy=0x15d6a00) at ../../src/OpenDis.c:837
#9  0x00007f377caa283f in XCloseDisplay (dpy=0x15d6a00) at ../../src/ClDisplay.c:80
#10 0x00007f377e81a83d in qt_cleanup () at kernel/qapplication_x11.cpp:2666

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 [details]
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 [details]
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 [details]
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 <kretschmann@kde.org>
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 <remi@remlab.net>
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 <jb@videolan.org>



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 [details]
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. ***