GNOME Bugzilla – Bug 351784
[xvimagesink] crash after BadAlloc X error
Last modified: 2015-08-14 11:13:34 UTC
Trying to playback: http://media.nextangle.com/rails/rails_setup.mov (Download it in full, a small amount won't make it crash) Will exit with: The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 64 error_code 11 request_code 140 minor_code 19) (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.) gstreamer-plugins-bad-0.10.3-2 gstreamer-plugins-good-devel-0.10.3.2-0.gst.1.5 gstreamer-plugins-base-0.10.9-0.gst.2.5 gstreamer-ffmpeg-0.10.1-0.gst.1.5 gstreamer-tools-0.10.9-0.gst.1.5 gstreamer-plugins-good-0.10.3.2-0.gst.1.5 gstreamer-plugins-base-devel-0.10.9-0.gst.2.5 gstreamer-0.10.9-0.gst.1.5 gstreamer-plugins-ugly-0.10.3.2-0.gst.1.5 gstreamer-devel-0.10.9-0.gst.1.5
Works fine for me with CVS of things. Could you post a stack trace.
Oh, also, could you run totem with GST_DEBUG_NO_COLOR=1 and GST_DEBUG=*:5 and attach the gzip'ed log file?
+ Trace 70831
Created attachment 71387 [details] rails-setup.log.bz2 Bzipped2 log
Can you still reproduce ? This looks like an insufficient memory kind of error.
*** Bug 432036 has been marked as a duplicate of this bug. ***
If the bug above really is a duplicate I have a video that triggers this in totem every time I try to play it.
> If the bug above really is a duplicate I have a video that triggers this in > totem every time I try to play it. Could you make it available somewhere? (catch us on IRC if you don't want to post the link here)
I've seen this bug when playing HD video, which leads me to believe that it's a problem allocating a large enough XV overlay. Try some pipelines: gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1080,height=720 ! xvimagesink gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1920,height=1280 ! xvimagesink In my particular case, there appears to be an X bug in addition to the xvimagesink, since xvinfo indicates a supported size of 1920x1088.
I have https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239125 opened downstream, which seems to be a problem with the intel modesetting driver.
*** Bug 434050 has been marked as a duplicate of this bug. ***
Whether or not it is a bug in the driver, the xvimagesink should report errors to the application, rather than bring the whole application down. It should use something similar to GDK's gdk_error_trap_push()/gdk_error_trap_pop().
Bastien, we used an error handler for a while at Nokia, but removed it again. Only the application can reliable do that. From the library its impossible to guarantee that the handler can be installed and remains effective :/
There's already an Xlib error handler set up in xvimagesink that is installed temporarily for certain high-risk operations. Pushing the first XVImage probably qualifies as "high-risk".
(In reply to comment #14) > There's already an Xlib error handler set up in xvimagesink that is installed > temporarily for certain high-risk operations. Pushing the first XVImage > probably qualifies as "high-risk". I can probably cook up a patch for that, if nobody beats me to it.
This happens every time I try to open a playlist from www.emusic.com...very annoying :-)
See also: http://bugs.freedesktop.org/show_bug.cgi?id=10912
Here's output from the two gst-launch lines in comment #9 [kmaraas@localhost gst-plugins-bad]$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1080,height=720 ! xvimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 140 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 45 Current serial number in output stream: 46 [kmaraas@localhost gst-plugins-bad]$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1920,height=1280 ! xvimagesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. FEIL: fra element /pipeline0/videotestsrc0: Could not negotiate format Tilleggsinformasjon for feilsøking: gstbasesrc.c(1865): gst_base_src_start (): /pipeline0/videotestsrc0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... [kmaraas@localhost gst-plugins-bad]$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1920,height=1280 ! xvimagesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. FEIL: fra element /pipeline0/videotestsrc0: Could not negotiate format Tilleggsinformasjon for feilsøking: gstbasesrc.c(1865): gst_base_src_start (): /pipeline0/videotestsrc0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... [kmaraas@localhost gst-plugins-bad]$
And I'm also using the intel driver...
*** Bug 461062 has been marked as a duplicate of this bug. ***
*** Bug 354698 has been marked as a duplicate of this bug. ***
*** Bug 553985 has been marked as a duplicate of this bug. ***
*** Bug 565987 has been marked as a duplicate of this bug. ***
There is a recent bug report in Ubuntu that seems to be related to this bug: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/327082. Here is the comment: "Every time the Totem application launches my screen goes black for a moment. If the application is opening with a file (e.g. I double click StopMotionUbuntu.ogv in the Examples folder) it crashes immediately. If I open the program using the Movie Player launcher in my Applications menu the display still goes blank, but the program doesn't crash until I open a file. In either scenario the program crashes without an error message and just disappears. This still happens if I turn Visual Effects off. If I start totem with the --debug flag and then open StopMotionUbuntu.ogv from the menu I get the following error report. $ totem --debug ** (totem:21552): DEBUG: Init of Python module ** (totem:21552): DEBUG: Registering Python plugin instance: BBCViewer+TotemPythonPlugin ** (totem:21552): DEBUG: Creating object of type BBCViewer+TotemPythonPlugin ** (totem:21552): DEBUG: Creating Python plugin instance ** (totem:21552): DEBUG: Init of Python module ** (totem:21552): DEBUG: Registering Python plugin instance: YouTube+TotemPythonPlugin ** (totem:21552): DEBUG: Creating object of type YouTube+TotemPythonPlugin ** (totem:21552): DEBUG: Creating Python plugin instance The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 67 error_code 11 request_code 140 minor_code 19) (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.)"
*** Bug 582067 has been marked as a duplicate of this bug. ***
Here's the output from GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:5 totem http://rapidshare.com/files/232425914/totem.log.bz2.html (requested in bug #582067) Totem 2.26.1, GStreamer 0.10.22, on GNOME 2.26.1
Still an issue with 1.0 ? So what's the actual bug here? We should somehow handle errors after / during the first Xv*PutImage() ?
(In reply to comment #27) > Still an issue with 1.0 ? > > So what's the actual bug here? We should somehow handle errors after / during > the first Xv*PutImage() ? Yep. Not that we care very much in Totem any more, as we use clutter to blit the image to the screen.
Do we care or not ? Is it still an issue with 1.0 playbin ?
I suspect it's still an issue with xvimagesink + playbin?