BadAlloc error when playing a video with xv if video resizes

Using Dapper Final, fully updated.

Wow. Both totem and mplayer crash due to an X BadAlloc error... It's odd that both of them suffer the same problem

Thanks for your bug. Do you use totem-gstreamer or totem-xine? Do you have any error if you run from a command line? What videocard and videodriver do you use? Do you use xgl or composite or some other experimental feature?

I have attached the error I get at the command line.

As stated in the title, I am running totem-gstreamer :).

I have a Dell Inspiron 510m (https://wiki.ubuntu.com/LaptopTestingTeam/DellInspiron510m
) with an Intel i855 videocard using the xorg-i810 driver.

I do not use XGL (much as I would like to) and the standard compositing manager. I have installed very little since a fresh install when Dapper Final was released.

I use 915resolution to get the correct resolution for my screen.

Marking this as confirmed because the question asked has been answered and William seems to be able to reproduce the error.

Is that specific to totem for you or does it happens also with mplayer as pointed by a previous comment or xine-ui? It might be a videodriver issue

Totem gives:
$ totem
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 49 error_code 11 request_code 141 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.)

---------------------
vlc gives:
~$ vlc
VLC media player 0.8.4 Janus
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: 82
  Current serial number in output stream: 83
pure virtual method called
terminate called without an active exception
Aborted

---------------
gxine gives:
$ gxine
lirc: cannot initialise - disabling remote control
lirc: maybe lircd isn't running or you can't connect to the socket?
The program 'gxine' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 486 error_code 11 request_code 141 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.)

So it looks like the error isn't in totem. To which package should this report be allocated?

Reassigning to xserver-xorg-video-i810

This seems to be caused by too big to be processed by Xv extension. It has been confirmed many times against many products (totem, istanbul...) and bug reports exist in X.org bugzilla.

This issue is probably very close to the one in bug #39050.

I found that exiting X (i.e. logging out of X, then relogging back in) seems to allow the Xv extension to play video again. It also doesn't always occur, its intermittent. This is on my laptop, having a Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) using the i810 driver for X. This is on a Dell Inspiron 640m.

I also do use 915resolution to drive the 1440x900 display. Can be repeated with totem, and vlc.

This is in Feisty Fawn, 64-bit edition.

This is not an Intel driver bug. I'm seeing the same issue here with a IBM ThinkPad T30 laptop with an external display.
Oddly, the issue happens only when starting a video in the external display with 1680x1050 resolution. Videos play
fine in the laptop display with 1025x768.

The video chipset:

ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]

For intel chips adding
Option "VideoRam" "65536"
Option "CacheLines" "1980"
to xorg.conf usually fixes this problem.

It fixes the crash problem but you still can't see any xv video output. It is black.

It's not usually a videoram detection issue . The only parameter that usually seems to solve the problem (at least on the machines I tested on) is CacheLines.

Please check this thread too - I'm sorry I forgot to put the comment here, too :

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/52490

The crash will probably be fixed by switching to the -intel driver in Gutsy (see bug 135141). The Xv issue I suspect may remain though.

I think this issue is fixed at least in Hardy?

> I think this issue is fixed at least in Hardy?

I'm still getting it - running latest Hardy on a laptop with a Intel 915 graphics chip, running driver i810.

It only seems to happen when playing high resolution (720p and up) videos. In earlier betas, this problem did not occur - it is only a recent occurrence on this install (started some time around Beta 2 or 3 I think)

I fixed it! Adding 'Option "LinearAlloc" "6144"' to my Xorg fixed it.

And now that I've put more thought into the matter, this problem may have started happening when I made a new xorg from scratch.

Hardy Heron Alpha5 was recently released. It contains an updated version of the Intel driver. You can download and try the new Hardy Heron Alpha5 Live CD from http://cdimage.ubuntu.com/releases/hardy/alpha-5/ . If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha5 .

-i810 driver is deprecated since Gutsy and shouldn't be used anymore if the -intel driver works fine. Afaik LinearAlloc, VideoRam or CacheLine options aren't needed anymore. Btw. Xv can only be used by one app but all other started video applications switch automatically back to standard xorg video output at least for me. This works fine in Gutsy so a recheck with a Gutsy Live CD should be enough. Maybe the xorg.conf has to be regenerated.

I guess this is a duplicate of Bug #124610 or vice versa.

It looks extremely similar to 124610 and is likely the same code path, however note that the error says opcode 141 here, but 140 in bug #124610. It may still be the same underlying problem though, but I think we should keep the bug reports independent for now.

Also, these kind of X errors are generally due to issues in the *calling* code rather than in X itself, so these may not actually be -intel bugs, just error conditions the media players are not prepared to handle. Indeed, the error message even says, "This probably reflects a bug in the program."