Google Earth and 3D Wine applications can crash X on close

Bug #401067 reported by Sandro Mani
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
High
mesa (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Running an up-to-date Ubuntu Karmic x86_64, hardware details attached.

Problem:
3D applications fail to run through wine without any exception. Furthermore, there is a 80% chance that the X server crashes after the attempt. The wine output reads:

fixme:d3d_caps:IWineD3DImpl_FillGLCaps Received unrecognized GL_VENDOR Tungsten Graphics, Inc. Setting VENDOR_WINE.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_A8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_X8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R5G6B5 rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:win:EnumDisplayDevicesW ((null),0,0x32f7e0,0x00000000), stub!

It does not make any difference whether I run compiz or metacity.

Plus, in case of an X crash, here's the backtrace:

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4eff56]
1: /usr/bin/X(xf86SigHandler+0x41) [0x480761]
2: /lib/libc.so.6 [0x7fdbd57f1cd0]
3: /usr/lib/dri/i965_dri.so(intelDestroyContext+0xeb) [0x7fdbd36c898b]
4: /usr/lib/dri/i965_dri.so [0x7fdbd36be820]
5: /usr/lib/xorg/modules/extensions//libglx.so [0x7fdbd4ada059]
6: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x6c) [0x7fdbd4acf9fc]
7: /usr/lib/xorg/modules/extensions//libglx.so [0x7fdbd4acfa33]
8: /usr/bin/X(FreeResourceByType+0x11f) [0x435e4f]
9: /usr/lib/xorg/modules/extensions//libglx.so [0x7fdbd4acc2ee]
10: /usr/lib/xorg/modules/extensions//libglx.so [0x7fdbd4acfc99]
11: /usr/bin/X(Dispatch+0x384) [0x44dff4]
12: /usr/bin/X(main+0x3b5) [0x433fa5]
13: /lib/libc.so.6(__libc_start_main+0xe6) [0x7fdbd57dd606]
14: /usr/bin/X [0x433429]

Tags: crash gm45 karmic

Related branches

Revision history for this message
Sandro Mani (sandromani) wrote :
Philip Muškovac (yofel)
affects: ubuntu → xserver-xorg-video-intel (Ubuntu)
Sandro Mani (sandromani)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi sandromani,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: crash
tags: added: needs-xorglog
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Revision history for this message
Sandro Mani (sandromani) wrote :

Hello,
Xorg.0.log is attached. Additionally I did some other testing, and I forgot to mention that the attempts often end with messages like

X Error of failed request: GLXBadDrawable
  Major opcode of failed request: 153 (GLX)
  Minor opcode of failed request: 5 (X_GLXMakeCurrent)
  Serial number of failed request: 505
  Current serial number in output stream: 505

Also here, if I try repeatedly, occasionally one attempt wont end with GLXBadDrawable but will either crash X or terminate on it's own/hang shortly after the

fixme:d3d_caps:IWineD3DImpl_FillGLCaps Received unrecognized GL_VENDOR Tungsten Graphics, Inc. Setting VENDOR_WINE.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_A8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_X8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R5G6B5 rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified.

block.
I have never found any (EE) entries after a crash in Xorg.0.log (or in any other log as I mentioned above...)

Revision history for this message
Sandro Mani (sandromani) wrote :

Also native linux applications seem to have problems: I tried compiling and running vdrift, and X froze as soon as a track finished loading. Soundplayback did continue for a while though, which seems to indicate that only X froze and not the whole system... Again, I did not find any helpful information in any logs...

Revision history for this message
Ryan Mills (sterben) wrote :

I can confirm this, I have the same issues with a Lenovo x200 intel x4500HD graphics card, jaunty with 2.6.31-020631rc3 kernel and various stable and unstable xserver-xorg-video-intel drivers. It is exactly as Sandro has described, sometimes crashing X, or throwing up an error, or giving the GLXBadDrawable error.

Revision history for this message
Ryan Mills (sterben) wrote :
Geir Ove Myhr (gomyhr)
tags: added: gm45 karmic
removed: needs-xorglog
Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Bryce Harrington (bryce)
summary: - [Intel Graphics] 3D application fail to run through Wine and often crash
- X
+ [GM45] 3D application fail to run through Wine and often crash X
Revision history for this message
Bryce Harrington (bryce) wrote : Re: [GM45] 3D application fail to run through Wine and often crash X

Please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions.

Also, you said, "The problem is very likely caused by a problem with the intel graphics driver." How are you reaching this conclusion?

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → High
Revision history for this message
Sandro Mani (sandromani) wrote :

Concerning the statement "The problem is very likely caused by a problem with the intel graphics driver.", I had a look at different setups and got the following results:
- Both Jaunty and Karmic, GM45 (the Lenovo T400 I am experiencing the problem on): crash as described
- Jaunty, proprietary ATI (HD3400) and proprietary NVIDIA: no problems of this kind (though I know nvidia has it's own driver framework)
- Jaunty, opensource ATI (Lenovo T60, x1400, xserver-xorg-video-ati): Often GlxBadDrawable errors, but once in a while the applications started without any subsequent crashing.
- Jaunty, older intel graphics (Intel GMA900): no problems of this kind

The crashing itself as described in the initial description only appeared using the intel driver on the GM45 chipset, therefore I suspect that the problem lies there. On the other hand the GlxBadDrawable error seems to be a more widespread problem, though I didn't have the chance to test the newest packages on the T60 system as I do not own the laptop.

I'll do some throughout testing according to http://wiki.ubuntu.com/X/Backtracing as soon as I get home this evening.

Revision history for this message
Sandro Mani (sandromani) wrote :

Okay, so I did some testing, and it looks like one of the updates in the past few days fixed the X crashing. Also, I did not experience any crashing or hanging anymore after testing some native Linux 3D applications.
What however remains is wine failing on any attempt to run a non-native 3D application, with the following scenarios (in order of probabiltiy):
1) Immediate GLXBadDrawable, wine exits
2) The usual sequence of "WINED3DFMT_A8R8G8B8" and similar error messages (as above) followed by a GLXBadDrawable + exit.
3) The usual "WINED3DFMT_A8R8G8B8" plus wine displaying an empty window frame, the should-be 3D content missing, manual CTRL+C to exit.

I also installed a separate karmic with the Xorg edgers PPA for testing, there X actually crashes like before.

Now, out of the blue (I have no experience in graphics related stuff), isn't it that some color format is simply not implemented in the driver (at least concerning the "WINED3DFMT_A8R8G8B8" errors)?
And concerning the GLXBadDrawable which are observable also with xserver-xorg-video-ati and possibly other drivers, is there any way to get additional debug information?

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → New
Revision history for this message
Bryce Harrington (bryce) wrote :

> I also installed a separate karmic with the Xorg edgers PPA for testing, there X actually crashes like before.

Then could we get a backtrace for this crash? And post an Xorg.0.log from this. Let me know exactly what versions of -intel, xserver, kernel, etc. you installed; maybe something in xorg-edgers has gotten out of date.

I'd like to focus this bug report just on the X crash issue, since that is a serious issue, and regardless of what wine does it should not make X crash.

For the other issue, while that sounds bad too, for sake of sanity in tracking I would ask that you establish a separate bug report for that. While there could well be an X fault underlying that, I would appreciate it if you would file it against wine, so they can have a look first, in case it is an issue they already know about. They can reassign to X if they conclude it needs a fix in X.

For some additional background... In some cases GlxBadDrawable errors can sometimes occur due to DRI/GLX not being enabled, although looking at your Xorg.0.log I'm not seeing evidence that this is the case. More generally, these are just client error message due to a failed xserver call (such as if the client was attempting to use an unavailable API). These sorts of errors typically should be handled at the client level - i.e. they are not bugs in X, but rather the client app.

All of the WINED3DFMT... stuff really appears to be error messages particular to wine.

Anyway, again, I'd like to focus just on the X crash.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Revision history for this message
Sandro Mani (sandromani) wrote :

Thanks for the background info!
I tried to obtain some backtraces with the xorg edgers packages, at the moment the only one I managed to get was the one appended at the end of the gdm log of the crashed session, which is attached.
Unfortunately gdb seems to hang X as soon as I attach it to the running instance of X, i.e. (but not the whole system, i.e. if I run sleep 30 && kill -s KILL $(pidof gdb) and then run gdb, first X locks up, but restores as soon as gdb gets killed). Also, a new X from gdb from a VT also locks up screen and inputs. I'll try later this evening with a second computer via ssh.

Revision history for this message
Sandro Mani (sandromani) wrote :

Just an update from my part: I am still trying to get a backtrace via gdb, but as before, as soon as I attach gdb to X, X hangs until I terminate it, no matter if I start gdb from a VT, via ssh or within the gdm session itself. I also tried to launch gdm via gdb, but I had some difficulties to provide the correct arguments to gdm-binary ... Also, referring to http://wiki.ubuntu.com/X/Backtracing , no "core" file exists in /etx/X11 after the crash and also apport stays quiet.
Was the gdm log attached in #11 of any use to you? Otherwise I'll keep trying.
Just a note: issue still present with latest xserver 1.6.3 and all the other updated edgers packages.

Revision history for this message
Bryce Harrington (bryce) wrote :

When X hangs when run through gdb, do you see a (gdb) prompt? If so, try typing 'cont'.

description: updated
Revision history for this message
Sandro Mani (sandromani) wrote :

I indeed forgot the cont via ssh... Anyway, backtrace attached.

Revision history for this message
Angel (angel-arancibia) wrote :

I'm having the same issue with wine 1.1.26 in jaunty 64bits. Logs attached.

lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

uname -a
Linux emma 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

Thanks in advance.

Revision history for this message
Sandro Mani (sandromani) wrote :

Just a short notice: as Bryce and often said above, this bug focuses on the occasional X crash. For the failure that only crashes / hangs wine (including GLXBadDrawable) I have opened a new bug #406865.

Revision history for this message
Sandro Mani (sandromani) wrote :

(The "and often" should not be there..)

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
zorgoth (freepskov) wrote :

I have this bug in Fedora 11, wine 1.1.27 too.

Revision history for this message
In , Bryce Harrington (bryce) wrote :
Download full text (6.0 KiB)

Forwarding this bug from Ubuntu reporter Sandro Mani:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/401067

[Problem]
Occasionally X crashes while using 3d apps in wine, using the Xorg edgers PPA. It does not crash with stock Karmic.

[Original Description]
Running an up-to-date Ubuntu Karmic x86_64, hardware details attached.

For some background, wine is failing on any attempt to run a non-native 3D application, with the following scenarios (in order of probability):
1) Immediate GLXBadDrawable, wine exits
2) The usual sequence of "WINED3DFMT_A8R8G8B8" and similar error messages (see below) followed by a GLXBadDrawable + exit.
3) The usual "WINED3DFMT_A8R8G8B8" plus wine displaying an empty window frame, the should-be 3D content missing, manual CTRL+C to exit.

The above can happen both with xorg-edgers and stock Karmic. But with xorg-edgers (only), it also can result in a crash of the X server. The X crash is what this bug report will focus on.

The wine output reads:

fixme:d3d_caps:IWineD3DImpl_FillGLCaps Received unrecognized GL_VENDOR Tungsten Graphics, Inc. Setting VENDOR_WINE.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_A8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_X8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R5G6B5 rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM rtInternal format is not supported as FBO color attachment.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:win:EnumDisplayDevicesW ((null),0,0x32f7e0,0x00000000), stub!

It does not make any difference whether I run compiz or metacity.

Xorg.0.log is attached. Additionally I did some other testing, and I forgot to mention that the attempts often end with messages like

X Error of failed request: GLXBadDrawable
  Major opcode of failed request: 153 (GLX)
  Minor opcode of failed request: 5 (X_GLXMakeCurrent)
  Serial number of failed request: 505
  Current serial number in output stream: 505

Also here, if I try repeatedly, occasionally one attempt wont end with GLXBadDrawable but will either crash X or terminate on it's own/hang shortly after the

fixme:d3d_caps:IWineD3DImpl_FillGLCaps Received unrecognized GL_VENDOR Tungsten Graphics, Inc. Setting VENDOR_WINE.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_A8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_X8R8G8B8 with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINE...

Read more...

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=28794)
gdb-xorg.txt

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=28795)
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.

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=28796)
lshw

Revision history for this message
Bryce Harrington (bryce) wrote : Re: [GM45] 3D application fail to run through Wine and often crash X

Sandro Mani - I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=23418 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Triaged
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Revision history for this message
Sandro Mani (sandromani) wrote :

Okay!

Revision history for this message
Sandro Mani (sandromani) wrote :

Just a notice: this bug is now also present with stock karmic packages, I suspect since the latest mesa update (7.6.0~git20090817.7c422387-0ubuntu2)

Revision history for this message
In , Idr (idr) wrote :

I think this may be fixed in xserver master by this commit:

commit 120286aef59dabdb7c9fa762e08457e5cc8ec3a6
Author: Michel Dänzer <email address hidden>
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?

Revision history for this message
In , Sandro Mani (sandromani) wrote :

Created an attachment (id=29398)
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.

Revision history for this message
In , Idr (idr) wrote :

(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.

Revision history for this message
In , Jaime Rave (jaimerave) wrote :

Hi Sandro, can you give a sample app than can be tested to provide more information. You can put the download link here.

Revision history for this message
In , Sandro Mani (sandromani) wrote :

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.

Revision history for this message
In , Brian Rogers (brian-rogers) wrote :

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.

Revision history for this message
In , Brian Rogers (brian-rogers) wrote :

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.

Revision history for this message
In , Brian Rogers (brian-rogers) wrote :

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.

Revision history for this message
In , Brian Rogers (brian-rogers) wrote :

Created an attachment (id=29520)
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.

Revision history for this message
In , Brian Rogers (brian-rogers) wrote :

Created an attachment (id=29521)
Testcase binary

Changed in xserver-xorg-video-intel:
status: Confirmed → In Progress
Revision history for this message
Marc Nieper-Wißkirchen (marc-nieper-wisskirchen) wrote : Re: [GM45] 3D application fail to run through Wine and often crash X

I can confirm this bug with the current Karmic testing version on my Dell Latitude XT 2 with a GM45 chipset (Intel 4500 MHD graphics).

Furthermore, I have also this bug without running wine at all: Running the linux version of the original Neverwinter Nights game by Bioware is fine - the game switches properly in fullscreen mode. Quitting the game, however, crashes X about 80% of the time.

(If you want to reproduce the bug, you can simply download the game resources and the linux client, which are available from Bioware. Running the game will show a screen where you are prompted to type in a valid CD key. When you abort this dialog, the game exits and X crashes.)

Revision history for this message
In , Idr (idr) wrote :

Adding Michel Dänzer to the CC list. He has worked in this area, so this might ring a bell for him.

Revision history for this message
In , Idr (idr) wrote :

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?

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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.

Revision history for this message
In , Idr (idr) wrote :

commit 2921a2555d0a76fa649b23c31e3264bbc78b2ff5
Author: Ian Romanick <email address hidden>
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.

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
Revision history for this message
In , Idr (idr) wrote :

*** Bug 22691 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Idr (idr) wrote :

*** Bug 22863 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Idr (idr) wrote :

*** Bug 23477 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Idr (idr) wrote :

*** Bug 22110 has been marked as a duplicate of this bug. ***

summary: - [GM45] 3D application fail to run through Wine and often crash X
+ Google Earth and 3D Wine applications can crash X on close
Revision history for this message
Brian Rogers (brian-rogers) wrote :

I put the fix for this in my PPA: https://launchpad.net/~brian-rogers/+archive/ppa

Revision history for this message
Albert Damen (albrt) wrote :

This bug has been fixed upstream. The commit is included in mesa 7.6 branch.

commit 2921a2555d0a76fa649b23c31e3264bbc78b2ff5
Author: Ian Romanick <email address hidden>
Date: Wed Sep 16 07:39:58 2009 -0700

    intel: Deassociated drawables from private context struct in
intelUnbindContext

If this commit is cherry-picked, you will probably also want the follow up fix:

commit 999592745f40a96a7307da374cab4d68254acf75
Author: Michel Dänzer <email address hidden>
Date: Mon Sep 21 10:08:11 2009 +0200

    intel: Fix crash in intel_flush().

    Since commit 2921a2555d0a76fa649b23c31e3264bbc78b2ff5 ('intel: Deassociated
    drawables from private context struct in intelUnbindContext'),
    intel->driDrawable may be NULL in intel_flush().

affects: xserver-xorg-video-intel (Ubuntu) → mesa (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mesa - 7.6.0~git20090817.7c422387-0ubuntu7

---------------
mesa (7.6.0~git20090817.7c422387-0ubuntu7) karmic; urgency=low

  * Add 110_deassociate_drawables.patch, 111_dridrawable_nullptr.patch:
    Fix X crash when 3D wine applications are closed.
    (LP: #401067)

 -- Bryce Harrington <email address hidden> Fri, 02 Oct 2009 18:00:02 -0700

Changed in mesa (Ubuntu):
status: Triaged → Fix Released
Changed in xserver-xorg-video-intel:
importance: Unknown → High
Changed in xserver-xorg-video-intel:
importance: High → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.