| Summary: | [GM45] 3D apps w/ Wine cause X Crash in driDestroyContext() | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Bryce Harrington <bryce> | ||||||||||||||
| Component: | Driver/intel | Assignee: | Ian Romanick <idr> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | high | CC: | brian, eric225125, eric, hanno, jaimerave, jassmith, linuxhippy, manisandro | ||||||||||||||
| Version: | 7.4 (2008.09) | Keywords: | regression | ||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Bryce Harrington
2009-08-19 14:40:50 UTC
Created attachment 28794 [details]
gdb-xorg.txt
Created attachment 28795 [details]
Xorg.0.log
This is an older Xorg.0.log (from well prior to collecting the backtrace). If a fresher Xorg.0.log would help, just ask.
Created attachment 28796 [details]
lshw
I think this may be fixed in xserver master by this commit: commit 120286aef59dabdb7c9fa762e08457e5cc8ec3a6 Author: Michel Dänzer <daenzer@vmware.com> Date: Thu Sep 3 08:05:59 2009 +0200 glx: Add screen DestroyWindow wrapper to destroy the GLX drawable. Fixes crashes exitting MacSlow's rgba-glx demo. Could you try that? Created attachment 29398 [details]
Wine output preceeding hang
Tested with the latest development snapshot of fedora 12, same hardware as in the attached lshw. Not wine neither crashes X nor crashes with a glx_baddrawable error, but instead completely locks up the computer at a point that even ssh hangs (i.e. I am able to connect but not to do anything else) - hard power-off is the only remaining option. The console output of wine is attached.
(In reply to comment #5) > Created an attachment (id=29398) [details] > Wine output preceeding hang > > Tested with the latest development snapshot of fedora 12, same hardware as in > the attached lshw. Not wine neither crashes X nor crashes with a > glx_baddrawable error, but instead completely locks up the computer at a point > that even ssh hangs (i.e. I am able to connect but not to do anything else) - > hard power-off is the only remaining option. The console output of wine is > attached. I have no idea what versions those are, so it's not a very useful data point. Do you know the SHA1 for the commits? From the Wine log, it looks like they're blindly trying to use a shader that failed to compile. Hi Sandro, can you give a sample app than can be tested to provide more information. You can put the download link here. Hello, sorry but I am indeed not very familiar with commit sha's... I tested on fedora because it was the distribution using the most recent snapshot of xorg7.5 that kame to my mind, namely 7.6.99.900 (1.7.0 RC 0) (built on 07 September 2009 02:00:06AM). This testcase was done with TrackMania United/Nations Forever, Nations can be freely downloaded at http://www.trackmania.com/index.php?rub=downloads. This program usually runs fine on Wine, notice you need to copy a d3dx9_36.dll (http://www.dll-files.com/dllindex/pop.php?d3dx9_36) to system32. Google Earth can trigger this as well. But I also have a small Windows app, with source code, that can trigger this bug. I'm going to strip it down to a minimum testcase and attach the source and binary. The problem appears to be memory corruption. A pointer is being overwritten by the time driDestroyContext() is called. It can be a different pointer each time, and sometimes the crash doesn't occur at all. Specifically, intel_fb (driDrawPriv->driverPrivate) is the corrupted pointer. It often winds up pointing into libc or what I believe is graphics memory (shows up as "/drm mm object (deleted)" in /proc/<pid>/maps). Surprisingly this doesn't always lead to a crash because the targeted memory often contains nulls or pointers to valid memory locations in the right places. I was able to get this out of valgrind: ==31602== Invalid read of size 8 ==31602== at 0xC29C0F4: intelDestroyContext (intel_context.c:877) ==31602== by 0xC28CB7A: driDestroyContext (dri_util.c:545) ==31602== by 0x80FE505: __glXDRIcontextDestroy (glxdri2.c:192) ==31602== by 0x80ED0A1: __glXFreeContext (glxext.c:211) ==31602== by 0x80ECD9F: ContextGone (glxext.c:110) ==31602== by 0x437D55: FreeResourceByType (resource.c:598) ==31602== by 0x80E333F: __glXDisp_DestroyContext (glxcmds.c:370) ==31602== by 0x80ED95E: __glXDispatch (glxext.c:578) ==31602== by 0x439AEC: Dispatch (dispatch.c:445) ==31602== by 0x42678A: main (main.c:285) ==31602== Address 0x1bbdc508 is 8 bytes inside a block of size 144 free'd ==31602== at 0x4C255FD: free (vg_replace_malloc.c:323) ==31602== by 0xC3796CC: _mesa_free (imports.c:85) ==31602== by 0xC28CB33: dri_put_drawable (dri_util.c:516) ==31602== by 0xC28CB50: driDestroyDrawable (dri_util.c:523) ==31602== by 0x80FE2B7: __glXDRIdrawableDestroy (glxdri2.c:105) ==31602== by 0x80ECF57: DrawableGone (glxext.c:163) ==31602== by 0x437C09: FreeResource (resource.c:562) ==31602== by 0x45AED1: CrushTree (window.c:877) ==31602== by 0x45AFF2: DeleteWindow (window.c:914) ==31602== by 0x437C09: FreeResource (resource.c:562) ==31602== by 0x43A78F: ProcDestroyWindow (dispatch.c:751) ==31602== by 0x439AEC: Dispatch (dispatch.c:445) There's a race. intelDestroyContext() and __glXDRIdrawableDestroy() can be called in either order when the program closes, but the Intel mesa code doesn't do refcounting on the drawable. So if intelDestroyContext() is called second, the drawable is already destroyed and free'd, and may already be overwritten. Crash. Created attachment 29520 [details]
Testcase
Install mingw32, then compile like so:
i586-mingw32msvc-gcc -Wall -o testcase.exe testcase.c -lopengl32 -lgdi32
Run it in wine and close it until you see the crash. It might take around five or six tries.
Created attachment 29521 [details]
Testcase binary
Adding Michel Dänzer to the CC list. He has worked in this area, so this might ring a bell for him. I'm going to try and fix this bug. However, the ONLY way I have found to get into __glXDRIdrawableDestroy is by calling glXDestroyWindow. glXDestroyWindow is part of GLX 1.3, and the current X server do *NOT* support GLX 1.3. Calling glXDestroyWindow is a bug in the application. Crashing because of it is a bug in the driver. How can the application (Wine, in this case) expect anything good to happen when it calls unsupported extension functions? (In reply to comment #14) > Adding Michel Dänzer to the CC list. He has worked in this area, so this > might ring a bell for him. Thanks, but no need, I read the xorg-team list. I didn't have any ideas, but it looks like you have a lead anyway. commit 2921a2555d0a76fa649b23c31e3264bbc78b2ff5 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Wed Sep 16 07:39:58 2009 -0700 intel: Deassociated drawables from private context struct in intelUnbindContext The generic DRI infrastructure makes sure that __DRIcontextRec::driDrawablePriv and __DRIcontextRec::driReadablePriv are set to NULL after unbinding a context. However, the intel_context structure keeps cached copies of these pointers. If these cached pointers are not NULLed and the drawable is actually destroyed after unbinding the context (typically by way of glXDestroyWindow), freed memory will be dereferenced in intelDestroyContext. This should fix bug #23418. *** Bug 22691 has been marked as a duplicate of this bug. *** *** Bug 22863 has been marked as a duplicate of this bug. *** *** Bug 23477 has been marked as a duplicate of this bug. *** *** Bug 22110 has been marked as a duplicate of this bug. *** |
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.