Summary: | [r300g] Memory corruption crash when exiting application using DRI2_InvalidateBuffers | ||
---|---|---|---|
Product: | Mesa | Reporter: | Chris Rankin <rankincj> |
Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Chris Rankin
2010-12-10 08:11:17 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. Just to Just to be clear: the crash only happens when WoW is run inside a window. It exits normally when run full-screen. 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. |
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.