(The glBindProgramARB is used as an example here, in general all calls which are remapped are affected) The example program is started with LIBGL_ALWAYS_INDIRECT=1 Call chain: The xserver receives a glXRender request with opcode 0x1054 == 4180 =^ glBindProgramARB. The index for the opcode is looked up in Render_dispatch_tree ( => 300), and Render_function_table[300] points to __glXDisp_BindProgramNV. Thus far, everything is correct. But looking at __glXDisp_BindProgramNV: │0x7ffff3093fa0 <__glXDisp_BindProgramNV> mov 0x255fb9(%rip),%rax # 0x7ffff32e9f60 │0x7ffff3093fa7 <__glXDisp_BindProgramNV+7> mov 0x4(%rdi),%esi │0x7ffff3093faa <__glXDisp_BindProgramNV+10> mov (%rdi),%edi │0x7ffff3093fac <__glXDisp_BindProgramNV+12> mov %fs:(%rax),%rax │0x7ffff3093fb0 <__glXDisp_BindProgramNV+16> mov 0x1890(%rax),%rax │0x7ffff3093fb7 <__glXDisp_BindProgramNV+23> jmpq *%rax tells that slot/offset 0x1890/8 == 786 is used. Now the dispatch table points to the Mesa internal dispatch table: (gdb) p ((_glapi_proc*)_glapi_tls_Dispatch)[0] $56 = (_glapi_proc) 0x7ffff19221c0 <_mesa_NewList> and slot 786 is: (gdb) p ((_glapi_proc*)_glapi_tls_Dispatch)[786] $57 = (_glapi_proc) 0x7ffff1991370 <_mesa_WindowPos3svMESA> whereas the correct slot is 798: (gdb) p ((_glapi_proc*)_glapi_tls_Dispatch)[798] $64 = (_glapi_proc) 0x7ffff190c620 <_mesa_BindProgram> This offset is defined in the *Mesa* dispatch.h: /usr/src/debug/Mesa-9.0.2/src/mesa/main/dispatch.h:#define BindProgramNV_remap_index 377 /usr/src/debug/Mesa-9.0.2/src/mesa/main/dispatch.h:#define _gloffset_BindProgramNV driDispatchRemapTable[BindProgramNV_remap_index] (gdb) p driDispatchRemapTable[377] $66 = 798
This happens due to the intel driver pulling in libglapi via libGL/Glamor. The result are 2 definitions of _glapi_add_dispatch, one from the X server (glx/glapi.c) and one from Mesa (mapi/mapi/mapi_glapi.c), and the wrong one wins. Disabling glamor in the intel driver works around this problem.
I believe I am seeing the same issue when trying to run the game Braid. I wrote some notes in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1073519
I see Stefan discussed this bug with Ian Romanick back in 2013: http://lists.freedesktop.org/archives/mesa-dev/2013-March/035907.html Subject: Mismatch between Mesas dispatch table and the one used by the X server Here's another instance of an X server crash due to incorrect GL dispatch, from May 2014: https://bugs.freedesktop.org/show_bug.cgi?id=78604#c17 commented by Michel Dänzer: [...] it looks like a GLX indirect GL dispatch issue. Reassigning, but I wouldn't hold my breath for that sort of thing getting fixed. :)
Created attachment 102088 [details] short reproducer Here is a small reproducer program that crashes Xorg reliably for me on Fedora 20. In current Fedora Rawhide it does not crash (presumably thanks to ajax's "GLX dispatch rewrite").
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/213.
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.