crash in drm_intel_gem_bo_start_gtt_access

Readily reproducible for me here, so if more info is needed, let me know.

The crash appears (based on a disassembly of the function with gdb - nothing so proper as catching a crash in action) to be happening at the line

    set_domain.handle = bo_gem->gem_handle;

when dereferencing bo_gem.

Please have a look at that bug:

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

Maybe is the same one?

No, these bugs don't appear to have any relation to one another.

Have twiddled a few knobs, and:

 (EE) intel(0): Cannot support DRI with frame buffer width > 2048.

this message in Xorg.0.log appears to be key. If I lower the virtual res in xorg.conf, I don't get the crash. If I subsequently set NoAccel, I still don't get the crash. It's only when I have my usual virtual res set (2960x1850) do I see the error. (This system doesn't work with UXA, so don't ask me to test that. :)

The first time I try to run totem, it errors out with this message:

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 76 error_code 11 request_code 132 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.)

There is a corresponding error in Xorg.0.log:

 (EE) intel(0): Failed to pin xv buffer

And then the second totem invocation will crash X.

Steve, thanks for chasing it down in gdb, but could you also put a trace onto this bug report?

Heh, of course as fate would have it, there's three exact instances of that line. Smells like a nullptr deref but a full backtrace would help in sorting it out.

A backtrace from gdb looks the same as the backtrace included in the bug description. Is there more specific information that you're looking for?

I had a closer look at the disassembly, the segfault is actually in the line

        ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain);

when resolving bufmgr_gem->fd.

I was able to reproduce this on my 945 and got a full backtrace.

The problem is in xxv-intel, src/i830_video.c
In I830PutImage:
    if (pPriv->buf == NULL) {
        pPriv->buf = drm_intel_bo_alloc(pI830->bufmgr,
                                        "xv buffer", alloc_size, 4096);
        if (pPriv->buf == NULL)
            return BadAlloc;
        if (!pPriv->textured && drm_intel_bo_pin(pPriv->buf, 4096) != 0) {
            drm_intel_bo_unreference(pPriv->buf);
            xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
                       "Failed to pin xv buffer\n");
            return BadAlloc;
        }
    }

The first time totem is run, pPriv->buf is NULL, a buffer is allocated and, given the failed to pin error message, pPriv->buf is now not NULL. drm_intel_bo_unreference frees the buffer, but does not set pPriv->buf back to NULL.
Therefore, next time totem is run, -intel will think we have a valid xv buffer and crash.

Attached patch solves the problem and makes totem return the BadAlloc error message every time. X no longer crashes.

As the same problem exists in git master, I will forward the bug and patch upstream.

Hi Steve, actually what I meant was I needed a full backtrace, like what Albert attached, sorry I wasn't more specific... been a long week.

Albert, thanks muchly for the analysis and patch. It looks good and I'll upload it tomorrow. Meanwhile please do see if you can get upstream's comment on it and let us know the bug number for future reference.

This bug was fixed in the package xserver-xorg-video-intel - 2:2.6.3-0ubuntu7

---------------
xserver-xorg-video-intel (2:2.6.3-0ubuntu7) jaunty; urgency=low

  * Add 119_drm_bo_unreference_needs_null.patch:
    - The first time through the Xv code, an allocated buffer is
      unreferenced but the pointer is not reset to NULL. Thus, the next time
      a video is played, -intel thinks it has a valid buffer and crashes
      when it tries to access the freed memory. Fixes a number of crashes
      reported since moving to the 2.6.3 driver.
    - Fixes crash on i945 with frame buffer width > 2048. DRI is disabled
      on this chipset when the frame buffer exceeds this width.
      (LP: #354688)
    - Fixes crash on i865 where DRI is off because of patch 116
      (LP: #352760)
    - Fixes crash on i845 starting after 304871 was fixed
      (LP: #354889)
    - Fixes crash on i830 when manually disabling DRI
      (LP: #347527)

 -- Bryce Harrington <email address hidden> Mon, 06 Apr 2009 14:28:29 -0700

Nice to see this one fixed.

in the server kernel we still have this problem but with generic and rt kernel it works fine here i have attached my lspci and other stuff anyway for me now there is not this problem anymore

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/356088

The issue I reported in bug 353023 is still not quite fixed. I don't get any crashes anymore, but I still can't play video, neither in mplayer nor in totem. Should I file a new bug about that?

I'm attaching my new Xorg.0.log file.

Me too, as in regard to Bug #351869. I have updated to the new xserver-xorg-video-intel this morning, (2:2.6.3-0ubuntu8) still unable to play video in VLC, totem etc.

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 82 error_code 11 request_code 132 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:

[????????] x11 video output error: X11 request 132.19 failed with error code 11:
 BadAlloc (insufficient resources for operation)
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 132 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 81
  Current serial number in output stream: 82

sorry cannot provide more information, cant use gdb yet.

I also can't play any video format at any video player (totem, kaffeine, mplayer, vlc, miro...). The outputs are the same presented by IcedEarth.

Workaround to get it working: open gstreamer-properties. Then, Video tab, Default Output section. Change the Plugin from "Autodetect" to "X Window System (No Xv)" and close. This way, totem will play any video format, but the other players still not working.

# uname -a
Linux laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

# lspci
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

# dpkg -l | grep xorg-video-intel
ii xserver-xorg-video-intel 2:2.6.3-0ubuntu9 X.Org X server -- Intel i8xx, i9xx display driver

I just updated my system (aptitude update & full-upgrade).

Is it necessary a full backtrace?

I confirm João's comment above. With the official jaunty release 2.6.3-0ubuntu9, video players crash when directed to use xv. Telling gstreamer not to use xv works around it.

In my case, video in vlc/mplayer/totem works fine initially, but if one forces a repaint of the screen, X will crash. In particular, hitting the hardware volume knobs (which cause a popup window with the volume level to appear overlaid on the video) causes the video to freeze and then X to crash.

Is this the same bug or is the original bug here truly fixed?

I just installed this update:
replacing: xserver-xorg-video-intel 2:2.6.3-0ubuntu9 (with .../xserver-xorg-video-intel_2%3a2.6.3-0ubuntu9.1_amd64.deb
It does NOT solve this bug, though I'am not sure it should but at least you now it is still there in the xserver-xorg-video-intel_2%3a2.6.3-0 package...

new bug for video playback failure in Jaunty: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/371275

Changing back to confirmed, there is not yet a fix (bug still occurs in a new install) there is a workaround as mentioned in
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/354688/comments/16

The crash bug *is* fixed. Other issues should be filed as separate reports (if they aren't already).