Bug 32297 - [r300g] Memory corruption crash when exiting application using DRI2_InvalidateBuffers
Summary: [r300g] Memory corruption crash when exiting application using DRI2_Invalidat...
Status: RESOLVED DUPLICATE of bug 31940
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2010-12-10 08:11 UTC by Chris Rankin
Modified: 2011-01-09 11:13 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Chris Rankin 2010-12-10 08:11:17 UTC
Tested with my RV350, Linux kernel, with WoW running in a 1152x864 window instead of full-screen. On exiting WoW, it crashes with the following stack trace:

=>0 0x7d88bbf7 dri2_invalidate_drawable+0x47(dPriv=*** Invalid address 0x0032eda8 ***
Internal symbol error: unable to access memory location 0x32eda8) [/home/chris/Programs/mesa/src/gallium/state_trackers/dri/drm/dri2.c:60] in r300_dri.so (0x0032edc0)
  1 0x7e9542fb dri2InvalidateBuffers+0x2a(dpy=*** Invalid address 0x0032edc8 ***
Internal symbol error: unable to access memory location 0x32edc8, drawable=*** Invalid address 0x0032edcc ***
) [/home/chris/Programs/mesa/src/glx/dri2_glx.c:678] in libgl.so.1 (0x0032ee00)
  2 0x7e95496f DRI2WireToEvent+0x11e(dpy=*** Invalid address 0x0032ee08 ***
Internal symbol error: unable to access memory location 0x32ee08, event=*** Invalid address 0x0032ee0c ***
Internal symbol error: unable to access memory location 0x32ee0c, wire=*** Invalid address 0x0032ee10 ***
Internal symbol error: unable to access memory location 0x32ee10) [/home/chris/Programs/mesa/src/glx/dri2.c:136] in libgl.so.1 (0x0032ee40)
  3 0x7e9a9dd1 _XEnq+0x60() in libx11.so.6 (0x0032ee90)
  4 0x7e9b0a64 in libx11.so.6 (+0x42a63) (0x0032eeb0)
  5 0x7e9b10f8 _XEventsQueued+0x67() in libx11.so.6 (0x0032eed0)
  6 0x7e9b119a _XFlush+0x49() in libx11.so.6 (0x0032eef0)
  7 0x7e988eb2 XFlush+0x31() in libx11.so.6 (0x0032f000)
  8 0x7dd7087a X11DRV_WindowPosChanged+0x199() in winex11 (0x0032f100)
  9 0x7ed2ff32 USER_SetWindowPos+0x6e1() in user32 (0x0032f240)
  10 0x7ed2f2d7 SetWindowPos+0xa6() in user32 (0x0032f2c0)
  11 0x7ed30e95 WINPOS_ShowIconTitle+0xf4() in user32 (0x0032f310)
  12 0x7ed31bd4 show_window+0x513() in user32 (0x0032f390)
  13 0x7ed31cdb ShowWindow+0x6a() in user32 (0x0032f3c0)
  14 0x007b2651 in wow (+0x3b2650) (0x0032f3d4)
  15 0x007b1008 in wow (+0x3b1007) (0x0032f444)
  16 0x7ed33e1a WINPROC_wrapper+0x19() in user32 (0x0032f474)
  17 0x7ed3456c call_window_proc+0x5b() in user32 (0x0032f4c4)
  18 0x7ed351fc WINPROC_CallProcWtoA+0x90b() in user32 (0x0032fb54)
Comment 1 Chris Rankin 2011-01-04 16:35:09 UTC
(In reply to comment #0)
> Backtrace:
> =>0 0x7d88bbf7 dri2_invalidate_drawable+0x47(dPriv=*** Invalid address
> 0x0032eda8 ***
> Internal symbol error: unable to access memory location 0x32eda8)

I've dug a bit further into this with the latest git code, and it looks like dri2_invalidate_drawable(dPriv) is (somehow) trying to use a garbage dri_context structure. Basically, the dPriv->driContextPriv->driverPrivate field seems to contain a value which is never allocated by dri_create_context(). I haven't determined how this value is set yet, but I'm suspecting memory corruption via a stale pointer because the dri_context struct that all previous dPriv->driContextPriv->driverPrivate fields had referred to had just been destroyed.

The previous backtrace seems to contain an invalid dPriv value instead, which isn't exactly what I'm seeing now either.
Comment 2 Chris Rankin 2011-01-04 17:48:12 UTC
Just to
Comment 3 Chris Rankin 2011-01-04 17:49:10 UTC
Just to be clear: the crash only happens when WoW is run inside a window. It exits normally when run full-screen.
Comment 4 Chris Rankin 2011-01-05 16:40:23 UTC
I think I've debugged this as far as I can; to get any further I'll need to find where the __DRIcontext.driverPrivate field is set to the "garbage"(?) value.

According to the fprintf() statements that I've littered throughout the Mesa/gallium code, where:

&__DRIcontext = 0x7d6f8d70
&struct dri_context = 0x7d13c4f0

Starting just before the crash:

** ENTER dri2_destroy_context: pcp->driContext=0x7d6f8d70, pcp->driContext->driverPrivate=0x7d13c4f0
** destroying dri_context 0x7d13c4f0
*** setting cPriv(0x7d6f8d70)->driverPrivate from 0x7d13c4f0 to NULL
** DONE dri2_destroy_context: pcp->driContext=0x7d6f8d70, pcp->driContext->driverPrivate=(nil)

So at this point, we have destroyed the dri_context at 0x7d13c4f0, and for good measure I have also explicitly NULLed out the __DRIcontext.driverPrivate field which referred to it. However, we then get this call to DRI2WireToEvent(), which triggers the fatal call to dri2InvalidateBuffers():

** ENTER DRI2WireToEvent
*** wire->u.u.type=0x4b
dri2 invalidate buffers: awire=0x7a56b4c8, awire->drawable=0x4800011
** ENTER dri2GetGlxDrawableFromXDrawableId
** found pdraw=0x7d775bd8 for drawable 0x4800011: cPriv=0x7d6f8d70, driverPrivate=0x7a5047a8
** ENTER dri2InvalidateBuffers: pdp->driDrawable->driContextPriv=0x7d6f8d70
** drawable IDs: 0x4800011 0x7d775c78
dri2_invalidate_drawable: dPriv=0x7d775c78, dPriv->driContextPriv=0x7d6f8d70, drawable=0x7d775cf8, ctx=0x7a5047a8, drawable->dPriv=0x7d775c78
wine: Unhandled page fault on read access to 0x0000003c at address 0x7d9710df (thread 000d), starting debugger...

This event fetches a struct dri2_drawable from the dri2Hash structure, which is linked to the __DRIcontext at 0x7d6f8d70 via driDrawable->driContextPriv. However, the driverPrivate field on this __DRIcontext structure is now set to 0x7a5047a8, which is a garbage value as far as I can tell. Chaos ensues when this value is mistaken for the address of a struct dri_context.

Interestingly, this problem actually DOES happen when WoW runs full-screen. However, the Wine debugger isn't started to tell me about it.

If anyone has any ideas on how to debug this further then I'm all ears. I've already tried using valgrind, but wine/WoW completely failed to run.
Comment 5 Chris Rankin 2011-01-09 11:13:16 UTC
The patch in #31940's comment 7 seems to fix the issue here as well. (So far, anyway...)

*** This bug has been marked as a duplicate of bug 31940 ***

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.