GNOME Bugzilla – Bug 590085
Playing video in queue crashes banshee
Last modified: 2010-02-19 01:01:23 UTC
Steps to reproduce: 1. Put audio followed by video in queue 2. play audio 3. double click video in queue Stack trace: banshee-1: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed. Stacktrace: Native stacktrace: banshee-1 [0x80c86a4] [0xb8077410] [0xb8077422] /lib/tls/i686/cmov/libc.so.6(gsignal+0x50) [0xb7e144c0] /lib/tls/i686/cmov/libc.so.6(abort+0x185) [0xb7e17b75] /lib/tls/i686/cmov/libc.so.6(__assert_fail+0x108) [0xb7e0d528] /usr/lib/libX11.so.6 [0xb65ddffd] /usr/lib/libX11.so.6(_XReply+0x106) [0xb65de526] /usr/lib/libX11.so.6(XSync+0x67) [0xb65d21a7] /usr/lib/libgdk-x11-2.0.so.0(gdk_display_sync+0x8f) [0xb6776c7f] /usr/lib/libgdk-x11-2.0.so.0(gdk_x11_drawable_get_xid+0xf8) [0xb67801c8] /usr/lib/banshee-1/libbanshee.so [0xb55a26fb] /usr/lib/libgstreamer-0.10.so.0 [0xb54ac06c] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2) [0xb6c4f102] /usr/lib/libgobject-2.0.so.0 [0xb6c65ae8] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7bd) [0xb6c66ecd] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26) [0xb6c67386] /usr/lib/libgstreamer-0.10.so.0(gst_bus_sync_signal_handler+0xb2) [0xb54ab392] /usr/lib/libgstreamer-0.10.so.0(gst_bus_post+0x106) [0xb54acd16] /usr/lib/libgstreamer-0.10.so.0(gst_element_post_message+0xb8) [0xb54b8288] /usr/lib/libgstreamer-0.10.so.0 [0xb54a7ce2] /usr/lib/libgstreamer-0.10.so.0 [0xb54dd23e] /usr/lib/gstreamer-0.10/libgstplaybin.so [0xb47f9e54] /usr/lib/gstreamer-0.10/libgstplaybin.so [0xb47e361d] /usr/lib/libgstreamer-0.10.so.0 [0xb54a8bed] /usr/lib/libgstreamer-0.10.so.0(gst_bus_post+0x106) [0xb54acd16] /usr/lib/libgstreamer-0.10.so.0(gst_element_post_message+0xb8) [0xb54b8288] /usr/lib/libgstreamer-0.10.so.0 [0xb54a Gdk-ERROR **: The program 'Banshee' received an X Window System error. This probably reflects a bug in the program. The error was 'BadIDChoice (invalid resource ID chosen for this connection)'. (Details: serial 31770 error_code 14 request_code 1 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... Other information: Haven't tried all the variations of different items in queue and how they are played (ie double-click, play button, next button, etc.. ) Shows the queue while playing the audio file, then when video is double-clicked, the queue window becomes the album art window of the audio file and then banshee crashes. I am using banshee-daily ppa on Karmic
Changing version, as the banshee-daily ppa tracks git master. I wasn't able to reproduce this problem. Are you able to play videos directly from your Video library ? Which version of GStreamer do you have on your system ?
I updated before reading my email and am also unable to reproduce this bug git20090728.r1.f86324f-0ubuntu1_i386 -> git20090729.r2.fd1c5ac-0ubuntu1_i386 Reinstalling did bring the crash back Guess I usually don't use banshee for video too much only when I'm listening to music so I had only noticed the queue thing, but yeah there are random crashes when just playing video, so it could just be my setup thats causing the crash libgstreamer0.10-0_0.10.23.4-1_i386 I'm probably reinstalling Karmic this weekend so I'll play around with it and reopen bug if I get any crashes off a cleaner system.
I also couldn't reproduce this with git and Karmic. Have you seen this bug in the past couple months?
I think I'm hitting this bug; it has to do with the client-side GTK windows branch being merged to trunk. Ubuntu Lucid has client-side windows enabled - this apparently makes GDK_WINDOW_XWINDOW not a trivial accessor and yields crash bugs when it's used outside of the gtk lock. GStreamer bug https://bugzilla.gnome.org/show_bug.cgi?id=599885 has more details. Judicious wrapping with gdk_threads_enter / gdk_threads_leave combined with gdk_window_ensure_native gets me to a point where video no longer crashes. Now, however, displaying coverart in the Now Playing window after a video has played crashes Banshee! You can check whether client-side windows is the culprit by running Banshee with the GDK_NATIVE_WINDOWS=yes environment variable set; this stops the crashes for me.
Ok. Here's a patch to fix this, following the style of the gstxoverlay documentation[1]. I can still trigger a non-deterministic crash switching between displaying video and displaying coverart but this occurs in HEAD and regardless of GDK_NATIVE_WINDOWS=yes, so is likely to be a separate bug. [1] http://www.gstreamer.net/data/doc/gstreamer/devel/gst-plugins-base-libs/html/gst-plugins-base-libs-gstxoverlay.html
Created attachment 153507 [details] [review] Fix for client-side windows, in the style of gstxoverlay documentation.
From the look of things, no more info is needed from the reporter. Changing from NEEDINFO to NEW.
Review of attachment 153507 [details] [review]: Looks good to me; just a few nitpicks ::: src/Backends/Banshee.GStreamer/Banshee.GStreamer/PlayerEngine.cs @@ +221,3 @@ } + public override void VideoWindowRealize (IntPtr window) Any reason not to make this (and the other VideoWindowRealize methods) protected? ::: src/Core/Banshee.ThickClient/Banshee.Gui.Widgets/TrackInfoDisplay.cs @@ +253,3 @@ return; } + Revert all these whitespace changes...
Created attachment 153602 [details] [review] As above, dropping the whitespace changes that crept in. I've stripped out the whitespace changes that accidentally remained. The various VideoWindowRealized methods need to be public because they're all called from outside the class: XOverlayVideoDisplay needs to call it on the PlayerEngineService, which needs to call it on it's active_engine PlayerEngine instance. Neither of these is a sublcass of PlayerEngine. I guess a protection level of “internal” would work, but I haven't seen that used elsewhere in the Banshee code, and it's more interesting for libraries.
Committed, thanks Christopher!