Bug 126307 - X11 error: BadAlloc (insufficient resources for operation) when trying to play video clips with other apps loaded
X11 error: BadAlloc (insufficient resources for operation) when trying to pla...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
http://freedesktop.org/bugzilla/show_...
: Triaged
: 80535 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-18 15:30 EDT by Motor
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-01 04:59:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My Xorg config file (3.71 KB, text/plain)
2004-06-18 15:32 EDT, Motor
no flags Details

  None (edit)
Description Motor 2004-06-18 15:30:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040510 Galeon/1.3.14

Description of problem:
Open a few galeon tabs with web sites loaded, or XMMS (or presumably
anything which uses a lot of X windows) and then try to play a video
clip using mplayer or xine causes problems: xine won't display video,
and mplayer bombs out in a more descriptive way (copy included below).
Closing galeon and XMMS allows the video to play with no other changes
to the setup. I've attached my xorg.conf file -- it was generated by
system-config-display, with a few font dirs added.


Version-Release number of selected component (if applicable):
xorg-x11-6.7.0-2

How reproducible:
Always

Steps to Reproduce:
1. Open a few galeon windows, with plenty of tabs loaded with
websites+XMMS+anything else. Doesn't work unless plent of tabs are
populated with websites -- and sometimes needs XMMS running too.
2. run command: mplayer videoclip.avi
    

Actual Results:  
>mplayer -v videoclip.avi

Starting playback...
[ffmpeg] aspect_ratio: 1.333333
VDec: vo config request - 320 x 240 (preferred csp: Planar YV12)
Trying filter chain: vo
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO Config (320x240->320x240,flags=0,'MPlayer',0x32315659)
VO: [xv] 320x240 => 320x240 Planar YV12
VO: Description: X11/Xv
VO: Author: Gerd Knorr <kraxel@goldbach.in-berlin.de> and others
Xvideo image format: 0x32595559 (YUY2) packed
Xvideo image format: 0x32315659 (YV12) planar
Xvideo image format: 0x30323449 (I420) planar
Xvideo image format: 0x59565955 (UYVY) packed
using Xvideo port 69 for hw scaling
[xv] dx: 0 dy: 0 dw: 320 dh: 240
*** [vo] Allocating (slices) mp_image_t, 320x240x12bpp YUV planar,
115200 bytes
[xv] dx: 0 dy: 0 dw: 320 dh: 240
*** [vo] Allocating (slices) mp_image_t, 320x240x12bpp YUV planar,
115200 bytes
X11 error: BadAlloc (insufficient resources for operation)
Type: 0, display: 9182cd0, resourceid: 2200001, serial: 56
Error code: b, request code: 8d, minor code: 13
 
 
MPlayer interrupted by signal 6 in module: flip_page
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We
can't and
  won't help unless you provide this information when reporting a
possible bug.
Uninit audio filters...
[libaf] Removing filter dummy
uninit audio: faad
FAAD: Closing decoder!
uninit video: ffmpeg
DEMUXER: freeing demuxer at 0x9133038
DEMUXER: freeing sh_audio at 0x913f968
DEMUXER: freeing sh_video at 0x91600c0
Xlib: unexpected async reply (sequence 0x59)!
vo: uninit ...


Expected Results:  Should have played


Additional info:

System specs:
Matrox G550 (32Mb RAM)
AMD Athlon XP2000+
Gigabyte Triton motherboard (VIA chipset)
512Mb RAM
Comment 1 Motor 2004-06-18 15:32:47 EDT
Created attachment 101246 [details]
My Xorg config file
Comment 2 Alan Cox 2004-06-18 18:45:23 EDT
X11 error: BadAlloc (insufficient resources for operation)
Type: 0, display: 9182cd0, resourceid: 2200001, serial: 56
Error code: b, request code: 8d, minor code: 13

This an application error. X  told the mplayer code that at it was not
at this time able to fulfill the request (almost certainly for the big
offscreen video buffers for the video overlay). Mplayer should have
fallen back to Xshm or handled the event nicely.

You should report this to mplayer instead.
Comment 3 Mike A. Harris 2004-06-24 13:11:32 EDT
*** Bug 80535 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Vander Stichele 2004-07-19 12:14:36 EDT
Hi,

I've ran into the same problem while fixing some bugs in GStreamer. 
So I took a day out to dig a bit deeper.  I'm not convinced it's only
an application error.

First of all, I don't see any way how the application can fall back
gracefully to some other method that allows it to display video.  If
you happen to know of one, please let me know.

Second, the root of the problem is the fact that both X overlays and
mapped pixmaps in the X server are stored in the video card's memory.
 Keith Packard tells me:

<keithp> thomasvs: oh, that's just broken video drivers.
<keithp> thomasvs: lame allocators that can't migrate pixmaps from
video memory to system memory to make space for the Xv buffer.

ie, when an application draws to an X overlay, the driver *should*
move away some mapped pixmaps from the video card to system memory. 
Unfortunately, it seems that not a lot of X drivers do this.

Now, the browser seems to be the one application that eats the most X
memory - easily more than 10 MB with a bunch of tabs open.  So the
problem can be verified by opening up a lot of tabs, until a video
application is unable to display using Xv.  Then start closing tabs
until the X memory usage is sufficiently low enough so that an X
overlay can be drawn to again.

Keith says that the correct place to fix this is in the X driver,
migrating pixmap data off of the card.  The browser should not try to
fix by unloading pixmap data itself, and the video application cannot
display video due to the memory depletion.

Can someone think of a good way out of this ?
Comment 5 Great Snoopy 2004-08-07 02:08:23 EDT
This IS a bug, and IS a bug in xorg. Saying that "mplayer should fall
back to shm" is plain stupid, as shm does not the same scaling
capabilities as xv. It's absurd to be impossible to do video
fullscreen because some apps are eating some video memory. 
Here is the link to prove that this IS a fscking BUG.

http://freedesktop.org/bugzilla/show_bug.cgi?id=474
Comment 6 Mike A. Harris 2004-08-07 03:02:08 EDT
Thanks Great Snoopy, we'll track this problem upstream now.

Setting status to UPSTREAM.
Comment 7 Great Snoopy 2004-08-07 16:22:45 EDT
You are welcome :)
And an additional note :
The normal behaviour of a modern video card (helped by the
driver, of course) is to use portions of standard video
memory when the videocard's memory is exhausted. Using means using
that memory directly or moving less used chunks of video memory back
into the main memory. This is why the AGP was created for, but it seems
that the xorg is not using it right.
It also seems that this problem has its origins in late pre 4.4
XFree86 sources and has been merged in xorg. There are many people
affected by this problem, and is not dependent on video driver. 
People with more video memory on their cards are less affected, but
the problem still exist on their setups, too.

I also could note that the suggested temporary workaround, 
    Option "XaaNoOffscreenPixmaps" in device section
works for many people,me included.

G-S
Comment 8 Great Snoopy 2004-08-07 16:27:13 EDT
You are welcome :)
And an additional note :
The normal behaviour of a modern video card (helped by the
driver, of course) is to use portions of standard video
memory when the videocard's memory is exhausted. Using means using
that memory directly or moving less used chunks of video memory back
into the main memory. This is why the AGP was created for, but it seems
that the xorg is not using it right.
It also seems that this problem has its origins in late pre 4.4
XFree86 sources and has been merged in xorg. There are many people
affected by this problem, and is not dependent on video driver. 
People with more video memory on their cards are less affected, but
the problem still exist on their setups, too.

I also could note that the suggested temporary workaround, 
    Option "XaaNoOffscreenPixmaps" in device section
works for many people,me included.

G-S
Comment 9 Michael Soulier 2004-08-20 22:49:58 EDT
This problem just hit my wife's computer, a brand new Dell Dimension
2400, running the i810 driver. FC2 is of no use to her now, so we'll
have to go with something else.

Where can I monitor the status of this issue upstream? Please provide
a link. 
Comment 10 Michael Soulier 2004-08-20 23:12:11 EDT
Scratch that. I just patched her system with xorg-x11-6.7.0-5 and the
problem is now gone. 
Comment 11 Mike A. Harris 2004-08-20 23:14:13 EDT
>Where can I monitor the status of this issue upstream? Please provide
>a link. 

See comment #5
Comment 12 Motor 2004-08-21 04:51:11 EDT
>Scratch that. I just patched her system with xorg-x11-6.7.0-5 and 
>the problem is now gone. 

I have xorg-x11.6.7.0-5 installed and the problem still occurs. BTW,
freedesktop link posted by Mike Harris has a workaround for the
problem (Option "XaaNoOffscreenPixmaps").
Comment 13 Mike A. Harris 2004-08-21 07:03:43 EDT
To the best of my knowledge, the problem described herein, and in
the currently open upstream bug report that we are tracking, is not
fixed in any Xorg release currently, nor in CVS head.  Unfortunately,
the problem is not marked as a release blocker in upstream bugzillz
either, and so it probably will not be addressed in the 6.8.0
release unless someone having the problem can convince the X.Org
developers it is a critical issue that should block the release.

Once it is fixed in upstream CVS however, we will review the fixes
that were commited to CVS, and if they are non-risky to apply to
6.7.0, we may consider backporting the upstream fixes to a future
FC2 update.

For the time being, it is best if everyone carbon copies themselves
on the upstream bug report, and follows up with upstream, as that
is where the issue is being tracked, and freedesktop.org developers
are probably not watching this bug in Red Hat bugzilla, so they'll
miss any valuable information provided here.

For reference, the upstream bug URL is:

    http://freedesktop.org/bugzilla/show_bug.cgi?id=474

Comment 14 Gigs 2004-10-20 09:30:33 EDT
The upstream bug has been closed on this now, is the fix in FC3-test?
Comment 15 Mike A. Harris 2004-10-20 17:03:48 EDT
Thanks for the info on the upstream bug.  Reopening for 
investigation for consideration in future xorg-x11 builds.
Comment 16 Jungshik Shin 2005-01-24 12:02:06 EST
With X.org 6.8.1 and 'nv' driver (my computer is Dell D800 with Nvidia
card), I still have the problem. I'm now trying 'Option
"XaaNoOffscreenPixmaps"'.
Comment 17 Mike A. Harris 2005-02-01 04:59:27 EST
Upstream claims this issue is fixed in 6.8.1 in the bug:

http://freedesktop.org/bugzilla/show_bug.cgi?id=474

so I am closing this as being fixed in FC3 "CURRENTRELEASE".  If
anyone still experiences this problem at all, please open a brand
new bug report in X.Org bugzilla, attaching all relevant details
to the new report.

Once your new bug report is filed in X.Org bugzilla, it will
eventually get reviewed by an X developer.  If they determine
there is a real bug present, and someone fixes it, we will
review the fix for consideration in future Fedora Core updates
if someone pastes the new bug URL into a Red Hat bug report.

Setting status to "CURRENTRELEASE"

Note You need to log in before you can comment on or make changes to this bug.