gstreamer crashes due to BadAlloc response from xv

This is the GDB crash log.

This is the strace log for the crash.

I am running the totem-gstreamer package, however I have tested the issue with totem-xine and it exists there too.

I don't get a crash here (totem-gstreamer 1.4.0-0ubuntu2 / xine libxine-main1 1.1.1+ubuntu2-6) on an nvidia x86 machine. What versions of the packages are you using?

scott@geneva:~$ dpkg -s totem-gstreamer | grep Version
Version: 1.4.0-0ubuntu2
scott@geneva:~$ dpkg -s xserver-xorg | grep Version
Version: 7.0.0-0ubuntu28

update and dist-upgrade pull in nothing new.

Thanks for the bug report - does this happen with other video sinks in 'gstreamer-properties'?

Does xine-ui crashes the same way? Could be an i810 driver issue

xine-ui works fine, as does the audio test and video test in the gstreamer-properties.

It occurs only in the X11/XShm/Xv output sink with totem. (To be expected, given the strace and gdb...)

Just so we're clear, it's _most_ movie files, not all of them.

still seems to be an Xv issue, are you sure than "xine --video-driver xv" works fine?

No, that displays a blue background. "xine --video-driver xshm" works. (kinda ;-), Xv is better.)

If this is an issue with the xserver, then I'll see if I can rollback the driver I'm running and see where it faulted. This issue has only recently appeared in dapper - previously everything was running fine!

"No, that displays a blue background" .... " "Xv is better"

Does Xv works or not?

Xv render output in xine displays a blue screen.

Ok, I have figured this out more. I've been playing with using gst-launch to setup test video streams.

It appears the Xserver kicks back a BadAlloc when an xvideo is setup at resolutions it doesn't like.

I would assume this is proper server behavior - but I don't know. I do know that the issue with the leaftag-gimmie.avi is the base resolution (1x scale) is larger than my display, and coincidently counted as a resolution the server doesn't like. Therefore, it kicks back BadAlloc.

Either totem or gstreamer should be handling this eventuality, yes?

Do you still have the issue? Could you get a debug backtrace?

Yes, I still have the issue and with help from the gstreamer guys I tracked it down.

Essentially, on a bunch of Xorg drivers, allocating a XVideo surface larger than the available memory will return a BadAlloc. gstreamer doesn't handle this, and therefore the crash.

Some developers in IRC noted it was a bug on their side, but I haven't had time to report it. However, it can be demonstrated easily with the following pipeline:

scott@geneva:~$ file leaftag-gimmie.avi
leaftag-gimmie.avi: RIFF (little-endian) data, AVI, 1024 x 768, 25.00 fps, video:
scott@geneva:~$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,height=1024,width=768 ! xvimagesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 141 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 46
  Current serial number in output stream: 47

have you planned to forward it upstream? it you do forward it could you update that bug to point to bugzilla.gnome page?

Thank you for the forward upstream

Rejecting the totem task as this is a bug in gst-plugins-base

upstream has a patch to try if somebody wants to play with it and let them know if it works correctly

Already on it. I'll give it a whirl later today.

That's a no-go.

I added the upstream patch into the debian/patches directory, and did a "debuild binary", and installed both the new -plugins-base and -x packages.

$ strings /usr/lib/gstreamer-0.10/libgstxvimagesink.so | grep "triggered an XError"
xvimagesink triggered an XError. error: %s
$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,height=1024,width=768 ! xvimagesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 141 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 49
  Current serial number in output stream: 50

Thank you for trying the patch, I've forwarded your comment upstream

Is this not merely a problem with i810's offscreen allocation for XV? See 'man i810'. I had this problem on my laptop with an 82855GM on Dapper (or Edgy, I forget); totem used to crash when loaded with large movies, or even without a movie due to the logo being too large, and straining XV's memory allocation. Setting:

Option "LinearAlloc" "8160"

in 'Section "Device"' of xorg.conf should help Intel users solve this problem.

Adding the LinearAlloc option to xorg.conf did it for me (after turning desktop effects off - that still produces a blank black surface in the window where the movie should to be (anyone have a bug number for this one?)).
lspci tells me I'm using an "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)".
The command run was "totem --sync --debug leaftag-gimmie.avi" and it's only output "** Message: Couldn't initialize lirc." which is perfectly ok.

If you're using i810, can you please test if switching to the -intel driver in Gutsy resolves this particular issue? If so, then the fix for 135141 will fix this bug as well.

I just switched to the Intel driver and can confirm the issue is resolved.

Thanks for testing, marking the driver bug as fixed.

Is the "intel" driver the one now auto-configured?

NM. Checked. It is.

This issue is still/again present in Jaunty Jackalope. The problem occurs with totem-gstreamer, but also with VLC player and mplayer. This can be circumvented by not using Xvideo (all players have options for this), e.g. use:

mplayer -vo gl
mplayer -vo x11

(as suggested in Bug 493360)

Here is the relevant section of the XOrg.log file:
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0 69.30 1280 1328 1360 1419 800 803 809 816 -hsync -vsync (48.8 kHz)
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x07330000 (pgoffset 29488)
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(EE) intel(0): Failed to pin xv buffer
(EE) intel(0): Failed to pin xv buffer
(EE) intel(0): Failed to pin xv buffer

Note that a similar issue is discussed in Bug 38939