The GL library fails to make a glX context active for a new thread if a context has been active for another thread before. I have written a small test program which shows this issue. What causes this bug is basically the following procedure: 1)In some thread, create an X window 2)Create a glx context 3)Make the glx context active 4)Make some gl calls 5)Unset the context 6)Destroy the context 7)Start a new thread 8)In that thread, create a new context 9)Set the new context to the window in the new thread 10)Do some GL calls from the new thread -> Crash There are no errors returned in any call, the problem shows up on the first GL call executed in the thread, e.g. glGetString(). The card is an radeon mobility 9000 card. This problem doesn't occur with Mesa software rendering, or with the ati fglrx or nvidia driver. I couldn't test any other card supported by dri. The background is that I am working on a Direct3D->OpenGL translator for Wine(www.winehq.com), and Wine is often confronted with applications doing multi-threaded 3D calls, as this is perfectly ok for D3D. Multithreaded d3d isn't supported in Wine by now, this bug applied for now only for apps which test if d3d works, uninitalize everything and re-initialize d3d from another thread and do not switch the thread again after this.
Created attachment 4908 [details] A small Xlib + opengl app illustrating the issue I've hacked this quick app to show the issue without referencing to Wine code. It's quite dirty as I've never done any raw X11 programming before. If it is doing something completely wrong, please drop me a note. This app crashes with the radeon driver from Xorg 7.0. The distribution is Gentoo.
I built and ran your program and cannot see a problem. Is it supposed to output one of the errors or crash? Radeon 9200, X.org 6.9. Output: String :1.3 Mesa 6.5 Thread! Calling glGetString now String :1.3 Mesa 6.5
The output it gave is what should happen, so you didn't hit the bug. If it hits the bug, it should crash or be killed. I just tried it on a system with an intel card, and here it seems to work too: String :1.3 Mesa 6.2.1 Thread! Calling glGetString now String :1.3 Mesa 6.2.1 From glxinfo: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 915G 20040919 x86/MMX/SSE2 I'll try it with Xorg7 and an Intel card.
OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20050831 AGP 8x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.5 [drm] Initialized radeon 1.24.0 20060225 on minor 0: Note: Mesa, libdrm, and radeon module were build from CVS on 17-03-2006
Seems to be a bug in my (old) driver version. I'll try to update and see if it works
Any news about this bug? Mesa/progs/xdemos/glthreads.c segfaults for same reason? Who is responcible for this bug: Mesa or Intel DRI driver? Any workaround? P.S. ctx.c works fine with NVidia binary drivers.
Run glthreads under gdb and post a backtrace.
glthreads.c backtrace: (gdb) r Starting program: /home/snob/tmp/a.out [Thread debugging using libthread_db enabled] [New Thread -1213474320 (LWP 14779)] threadgl: test of GL thread safety (any key = exit) Usage: threadgl [-display dpyName] [-n numthreads] XInitThreads() returned 1 (success) [New Thread -1283605600 (LWP 14782)] Created Thread -1283605600 [New Thread -1291998304 (LWP 14783)] Created Thread -1291998304 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1283605600 (LWP 14782)] 0xb7908fbe in intelInitDriverFunctions () from /usr/X11R6/lib/modules/dri/i915_dri.so (gdb) bt #0 0xb7908fbe in intelInitDriverFunctions () from /usr/X11R6/lib/modules/dri/i915_dri.so #1 0xb7929796 in _mesa_make_current () from /usr/X11R6/lib/modules/dri/i915_dri.so #2 0xb7908984 in intelMakeCurrent () from /usr/X11R6/lib/modules/dri/i915_dri.so #3 0xb78f16ae in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules/dri/i915_dri.so #4 0xb7eb7a6c in glXDestroyContext () from /usr/lib/libGL.so.1 #5 0xb7eb9912 in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #6 0xb7eb9ba3 in glXMakeCurrent () from /usr/lib/libGL.so.1 #7 0x08049276 in draw_loop (wt=0x804b040) at glthreads.c:150 #8 0x08049831 in thread_function (p=0x804b040) at glthreads.c:303 #9 0xb7bf234b in start_thread () from /lib/libpthread.so.0 #10 0xb7cbf65e in clone () from /lib/libc.so.6 (gdb) P.S. I've modified attached ctx.c example to use XInitThreads, XLockDisplay, etc. Nothing changes. Here is gdb backtrace: (gdb) r Starting program: /home/snob/tmp/ctx2 [Thread debugging using libthread_db enabled] [New Thread -1213593104 (LWP 14891)] String :1.3 Mesa 6.4.2 [New Thread -1280169056 (LWP 14894)] Thread! Calling glGetString now Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1280169056 (LWP 14894)] 0xb79291f8 in _mesa_GetString () from /usr/X11R6/lib/modules/dri/i915_dri.so (gdb) bt #0 0xb79291f8 in _mesa_GetString () from /usr/X11R6/lib/modules/dri/i915_dri.so #1 0x080489f2 in thread (arg=0x0) at ctx2.c:36 #2 0xb7bd534b in start_thread () from /lib/libpthread.so.0 #3 0xb7ca265e in clone () from /lib/libc.so.6 (gdb)
Make sure you've got the latest version of Mesa from CVS which will compile with debugging enabled, and re-run glthread under gdb which will provide much better backtrace details.
You mean "i810 DRI driver with full debugging info"? This will take several days, I'm currently installing Gentoo for that purpose. Maybe, somebody with already installed "latest" sources can confirm this behaviour?
Your test program is flawed. You can't just create your own XVisualInfo structure by filling in the fields yourself. You need to a visualinfo returned by glXChooseVisual(), or XMatchVisualInfo(), etc. As it is, Mesa's getting totally confused by the fact that the visualinfo you're constructing is inconsistant with what's returned by XDefaultVisual(disp, XDefaultScreen(disp).; There's several programs in Mesa/progs/xdemos/ that you can look at for examples. After you've fixed your program, either close this bug if things work, or attach the new test program.
The bug is fixed for me in Xorg 7.1, I have no idea if the intel crash is related. From my point of view we can close the bug. The 'real' application that crashed for me was Microsoft's DirectX diagnosis tool when running the D3D test. This works fine now with Xorg 7.1 and current Wine.
Marking this report as invalid. Re-open or file a new report if needed.
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.