I reported this bug first in the Debian BTS at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626646 .
Per the comments of Cyril Brulebois in that bug entry, I tested freedesktop.org xf86-video-intel git master merged to the Debian packaging repository of xserver-xorg-video-intel. It seems the bug is still present in master/HEAD of xf86-video-intel as of commit 9d6e02a1 (HEAD as of today May 28).
I can pretty reproducibly either crash the X server or corrupt the display, sometimes permanently, by exiting the fullscreen mode of the proprietary flash player while it plays video. After compiling the X server with no optimizations and running it under valgrind, I believe the reason is a use after free in i830_dri2_frame_event_drawable_gone(). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626646#10 .
Here is the valgrind error message which I get when exiting fullscreen mode (this message is against current git master, the one against the version in Debian unstable is in the Debian BTS message #10):
==29640== Invalid write of size 4
==29640== at 0x8BCFD00: i830_dri2_frame_event_drawable_gone (intel_dri.c:598)
==29640== by 0x45D38A: FreeResource (resource.c:596)
==29640== by 0x42E38A: ProcDestroyWindow (dispatch.c:732)
==29640== by 0x42D734: Dispatch (dispatch.c:431)
==29640== by 0x425A3A: main (main.c:287)
==29640== Address 0xcc80310 is 0 bytes inside a block of size 56 free'd
==29640== at 0x40267AE: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29640== by 0x8BD0522: I830DRI2FrameEventHandler (intel_dri.c:844)
==29640== by 0x8BAFDA9: intel_vblank_handler (intel_display.c:1517)
==29640== by 0x8796A1A: drmHandleEvent (in /usr/lib/libdrm.so.2.4.0)
==29640== by 0x8BAFEF6: drm_wakeup_handler (intel_display.c:1564)
==29640== by 0x43B47D: WakeupHandler (dixutils.c:419)
==29640== by 0x479090: WaitForSomething (WaitFor.c:235)
==29640== by 0x42D55F: Dispatch (dispatch.c:367)
==29640== by 0x425A3A: main (main.c:287)
Looking at the code, the offending write happens in intel_dri.c:
593 static int
594 i830_dri2_frame_event_drawable_gone(void *data, XID id)
596 DRI2FrameEventPtr frame_event = data;
** 598 frame_event->drawable_id = None;
599 return Success;
And the frame_event structure presumably has been previously freed here in the same file:
760 void I830DRI2FrameEventHandler(unsigned int frame, unsigned int tv_sec,
761 unsigned int tv_usec, DRI2FrameEventPtr swap_info)
763 DrawablePtr drawable;
764 ScreenPtr screen;
842 I830DRI2DestroyBuffer(drawable, swap_info->front);
843 I830DRI2DestroyBuffer(drawable, swap_info->back);
** 844 free(swap_info);
GDB crash logs, glxinfo output, lspci output, Xorg.log, udev information, kernel log and lots of other details you probably do not care that much about are nonetheless available in my original bug report to the Debian BTS:
If you need any further information or debugging, I will be happy to be of assistance.
I can reproduce this issue with xorg-server 1.10.2, mesa 7.10.2 and libdrm 2.4.26 and x11-driver-video-intel 2.15 on Mandriva cooker.
Another easy way to reproduce the issue is:
- execute tuxracer in fullscreen mode
- run a game
- return to menu
- wait on menu screen about 30 seconds
- hit esc to leave the application.
As soon as desktop returns, X crashes.
Created attachment 47731 [details] [review]
Tentative patch fixing the crash
This patch fixed the issue for me.
(Adjusting Product as the proposed patch fixed the issue within Mesa).
Tested. That patch doesn't fix the crash here, so we may be talking about two distinct bugs.
(In reply to comment #3)
> Created an attachment (id=47731) [details]
> Tentative patch fixing the crash
> This patch fixed the issue for me.
By looking at the patch, I suspect your problem might be a duplicate of:
Look at the patch in #32534 comment #5
Yes, could be a duplicate of #32534 indeed.
Author: Chris Wilson <email@example.com>
Date: Mon Jul 11 16:28:15 2011 +0100
dri: Prevent abuse of the Resource database
The Resource database is only designed to store a single value for a
particular type associated with an XID. Due to the asynchronous nature
of the vblank/flip requests, we would often associate multiple frame
events with a particular drawable/client. Upon freeing the resource, we
would not necessarily decouple the right value, leaving a stale pointer
behind. Later when the client disappeared, we would write through that
stale pointer upsetting valgrind and causing memory corruption. MDK.
Instead, we need to implement an extra layer for tracking multiple
frames within a single Resource.
Signed-off-by: Chris Wilson <firstname.lastname@example.org>