Bug 37700 - Screen corruption and crash apparently due to use of freed memory
Summary: Screen corruption and crash apparently due to use of freed memory
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 7.10
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact:
Keywords: patch
Depends on:
Reported: 2011-05-28 11:54 UTC by Sami Liedes
Modified: 2011-07-11 14:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Tentative patch fixing the crash (969 bytes, patch)
2011-06-08 12:28 UTC, Eugeni Dodonov
Details | Splinter Review

Description Sami Liedes 2011-05-28 11:54:03 UTC
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)
   595 {
   596         DRI2FrameEventPtr       frame_event = data;
** 598         frame_event->drawable_id = None;
   599         return Success;
   600 }

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)
   762 {
   763         DrawablePtr drawable;
   764         ScreenPtr screen;
   841         i830_dri2_del_frame_event(swap_info);
   842         I830DRI2DestroyBuffer(drawable, swap_info->front);
   843         I830DRI2DestroyBuffer(drawable, swap_info->back);
** 844         free(swap_info);
   845 }

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.
Comment 1 Eugeni Dodonov 2011-06-08 11:30:09 UTC
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.
Comment 2 Eugeni Dodonov 2011-06-08 11:33:10 UTC
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.
Comment 3 Eugeni Dodonov 2011-06-08 12:28:24 UTC
Created attachment 47731 [details] [review]
Tentative patch fixing the crash

This patch fixed the issue for me.
Comment 4 Eugeni Dodonov 2011-06-08 13:10:25 UTC
(Adjusting Product as the proposed patch fixed the issue within Mesa).
Comment 5 Sami Liedes 2011-06-08 13:54:06 UTC
Tested. That patch doesn't fix the crash here, so we may be talking about two distinct bugs.
Comment 6 Paulo Zanoni 2011-06-08 14:16:22 UTC
(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
Comment 7 Eugeni Dodonov 2011-06-08 14:27:14 UTC
Yes, could be a duplicate of #32534 indeed.
Comment 8 Chris Wilson 2011-07-11 14:25:12 UTC
commit 2608a367acba7247e50754c3daeed09ba2e97d05
Author: Chris Wilson <chris@chris-wilson.co.uk>
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.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37700
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.