When running glxgears (or tunnel...) with LIBGL_ALWAYS_INDIRECT=1 set or with no DRI driver available the Xserver will crash when you move the window around. here is the snippet from the Xorg log: *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Backtrace: 0: X(xf86SigHandler+0x7f) [0x8085daf] 1: [0xffffe420] 2: /usr/X11R6/lib/modules/extensions/libGLcore.so(_mesa_memset+0x23) [0x40389ba3] 3: /usr/X11R6/lib/modules/extensions/libGLcore.so [0x4039957d] 4: /usr/X11R6/lib/modules/extensions/libGLcore.so(_swrast_Clear+0x6b3) [0x403e3303] 5: /usr/X11R6/lib/modules/extensions/libGLcore.so [0x4047ad13] 6: /usr/X11R6/lib/modules/extensions/libGLcore.so(_mesa_Clear+0x13b) [0x40339e4b] 7: /usr/X11R6/lib/modules/extensions/libGLcore.so(glClear+0x25) [0x40310445] 8: /usr/X11R6/lib/modules/extensions/libglx.so(__glXDisp_Clear+0x1e) [0x402a9c9e] 9: /usr/X11R6/lib/modules/extensions/libglx.so(__glXRender+0xd5) [0x402be8d5] 10: /usr/X11R6/lib/modules/extensions/libglx.so [0x402c2055] 11: X(Dispatch+0x14f) [0x80c169f] 12: X(main+0x40b) [0x80cd8db] 13: /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40080500] 14: X [0x806fd11] Fatal server error: Caught signal 11. Server aborting Please consult the The X.Org Foundation support at http://wiki.X.Org
The crash still occurs with current XORG-CVS HEAD.
I have a similar bug when I move or resize glxgears. Xorg CVS from 20050913 (Mandriva cooker) Radeon Mobility X600 with DRI disabled pentium M sonoma (with NX bit enabled) backtrace: 0: /etc/X11/X(xf86SigHandler+0x88) [0x8089668] 1: [0xffffe420] 2: /usr/X11R6/lib/modules/extensions/libGLcore.so [0xb7b3378a] 3: /usr/X11R6/lib/modules/extensions/libGLcore.so(_swrast_clear_depth_buffer+0x31d) [0xb7b896ed] 4: /usr/X11R6/lib/modules/extensions/libGLcore.so(_swrast_Clear+0x34b) [0xb7b8442b] 5: /usr/X11R6/lib/modules/extensions/libGLcore.so [0xb7c22133] 6: /usr/X11R6/lib/modules/extensions/libGLcore.so(_mesa_Clear+0x179) [0xb7acc989] 7: /usr/X11R6/lib/modules/extensions/libGLcore.so(glClear+0x26) [0xb7aa0246] 8: /usr/X11R6/lib/modules/extensions/libglx.so(__glXDisp_Clear+0x1f) [0xb7ce23ef] 9: /usr/X11R6/lib/modules/extensions/libglx.so(__glXRender+0xcf) [0xb7cfa8bf] 10: /usr/X11R6/lib/modules/extensions/libglx.so [0xb7cfd344] 11: /etc/X11/X(Dispatch+0x15e) [0x80ca21e] 12: /etc/X11/X(main+0x407) [0x80d73f7] 13: /lib/tls/libc.so.6(__libc_start_main+0xd0) [0xb7e60e40] 14: /etc/X11/X [0x8070121] Fatal server error: Caught signal 11. Server aborting
*** Bug 4484 has been marked as a duplicate of this bug. ***
Similar crash here. My scenario is maximizing a glxgears window with DRI completely disabled; the server SIGSEGVs after about one to four tries. Backtracing pinpoints the crash in flat_8R8G8B_z_triangle()---in a nutshell, pRow is pointing to invalid memory. I think that xmesa_alloc_storage() was previously called with bogus args. Here's an excerpt from my GDB session: ----(begin)---- (gdb) up #7 0x081e8536 in xf86SigHandler (signo=11) at xf86Events.c:1414 1414 FatalError("Caught signal %d. Server aborting\n", signo); (gdb) up #8 <signal handler called> (gdb) up #9 0x084541c6 in flat_8R8G8B_z_triangle (ctx=0x89c28a0, v0=0xafc08020, v1=0xafc080c4, v2=0xafc0820c) at s_tritemp.h:1182 1182 s_tritemp.h: No such file or directory. in s_tritemp.h (gdb) p pRow $1 = (GLuint *) 0xafb64d84 (gdb) p pRow[0] Cannot access memory at address 0xafb64d84 (gdb) p *xrb $2 = {Base = {Name = 0, RefCount = 1, Width = 0, Height = 0, InternalFormat = 6408, _BaseFormat = 6408, DataType = 5121, ComponentSizes = "\000\000\000", Data = 0x0, Delete = 0x8413e58 <xmesa_delete_renderbuffer>, AllocStorage = 0x8413e5d <xmesa_alloc_storage>, GetPointer = 0x84cd132 <nop_get_pointer>, GetRow = 0x84358d8 <get_row_rgba>, GetValues = 0x8436b96 <get_values_rgba>, PutRow = 0x842858a <put_row_8R8G8B_ximage>, PutRowRGB = 0x8428dab <put_row_rgb_8R8G8B_ximage>, PutMonoRow = 0x8432496 <put_mono_row_8R8G8B_ximage>, PutValues = 0x842fcf2 <put_values_8R8G8B_ximage>, PutMonoValues = 0x843407a <put_mono_values_8R8G8B_ximage>}, pixmap = 0x0, ximage = 0x907e2d0, origin1 = 0xafb7db58 <Address 0xafb7db58 out of bounds>, width1 = 1200, origin2 = 0xafb7db58, width2 = 600, origin3 = 0xafb7db58 <Address 0xafb7db58 out of bounds>, width3 = 1200, origin4 = 0xafb7db58, width4 = 300, bottom = -1, clearFunc = 0x8414c84 <clear_32bit_ximage>} (gdb) p *xrb->ximage $3 = {width = 300, height = 300, data = 0xafb7e008 "", bytes_per_line = 1200, bits_per_pixel = 32} (gdb) ----(end)---- Notice how the xrb->originN pointers refer to memory _before_ the xrb->ximage->data region (as does pRow). I believe this is because xmesa_alloc_storage() was called with a height argument of 0---it uses (height - 1) in various multiplications. (Should it be legal to call that function with height==0?) Oh, and all this is with the Mesa code in the xorg CVS tree. Mesa CVS has some newer material, but to judge from my [very] cursory glance at it, they haven't come across this issue yet.
Something glx related has been changed in the xc CVS tree, so I tried if it fixed this bug: unfortunately the bug is still there.
(In reply to comment #4) > Similar crash here. My scenario is maximizing a glxgears window with DRI > completely disabled; the server SIGSEGVs after about one to four tries. Can you explain what you mean by "one to four tries"? Does that mean starting and stoping glxgears one to four time, or does it mean something else? > Backtracing pinpoints the crash in flat_8R8G8B_z_triangle()---in a nutshell, > pRow is pointing to invalid memory. I think that xmesa_alloc_storage() was > previously called with bogus args. Here's an excerpt from my GDB session: That seems like a fair assessment, but I'm not sure how that could happen. > Oh, and all this is with the Mesa code in the xorg CVS tree. Mesa CVS has some > newer material, but to judge from my [very] cursory glance at it, they haven't > come across this issue yet. Are you able to reproduce this when building X.org with the Mesa 6.4 branch? That branch is going to be merged into X.org soon, so I don't want to spend a lot of time digging into a bug that's already fixed. :) Thanks for retesting this issue after my 9/28 commits, BTW.
Bug is still in XORG-CVS. @idr: what is the easiest way to build Xorg with Mesa-CVS or with Mesa-CVS-6-4-branch? Or how is it possible to build the libGLcore.so in the Mesa tree?
OK, I reproduced the problem here and found the cause. I've checked in the fix to Mesa CVS.
Created attachment 3598 [details] [review] Enable building X.org CVS with Mesa 6.4. (In reply to comment #7) > @idr: what is the easiest way to build Xorg with Mesa-CVS or with > Mesa-CVS-6-4-branch? > Or how is it possible to build the libGLcore.so in the Mesa tree? Since some source files have been added and removed in the Mesa 6.4 tree, some changes are required. Apply this patch and add a line like this to your config/cf/host.def file: #define MesaSrcDir /home/idr/devel/graphics/Mesa-6.4
I built Xorg with mesa_6_4_branch and now I can't trigger the crash anymore. Thanks!
Hello, unfortunately I discoverd that running quake3 from http://icculus.org/quake3/ crashs the Xserver, but with another error: *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Backtrace: 0: X(xf86SigHandler+0x7f) [0x808634f] 1: [0xffffe420] 2: /usr/X11R6/lib/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x35) [0x40489005] 3: /usr/X11R6/lib/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x63) [0x404853a3] 4: /usr/X11R6/lib/modules/extensions/libGLcore.so(__MESA_resizeBuffers+0x59) [0x 404841a9] 5: /usr/X11R6/lib/modules/extensions/libglx.so(__glXResizeBuffers+0x2e) [0x402ccc0e] 6: /usr/X11R6/lib/modules/extensions/libglx.so(__glXResizeDrawableBuffers+0x5d) [0x402d27ed] 7: /usr/X11R6/lib/modules/extensions/libglx.so [0x402d2459] 8: X(compPositionWindow+0x46) [0x8155e46] 9: X(ReparentWindow+0x194) [0x80d8094] 10: X(ProcReparentWindow+0x95) [0x80c1bf5] 11: X(Dispatch+0x14f) [0x80c20bf] 12: X(main+0x40b) [0x80ce32b] 13: /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40088500] 14: X [0x806ff41] Fatal server error: Caught signal 11. Server aborting The strange thing is, that I wanted it to run with the Radeon DRI driver, but this driver from mesa-6-4-branch built in the Xorg tree isn't working: > glxinfo name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/radeon_dri.so failed (/usr/X11R6/lib/modules/dri/radeon_dri.so: undefined symbol: mmFindBlock) libGL error: unable to find driver: radeon_dri.so display: :0 screen: 0 direct rendering: No You can get quake3 src via svn: svn co svn://svn.icculus.org/quake3/trunk quake3 then backup all "ID-original" files from your /usr/local/games/quake3 directory, then: make cd code/unix make copyfiles and you might at least need the demo pak0.pk3 file from q3demo.
mmFindBlock() is found in src/mesa/main/mm.c (formerly in src/mesa/dri/common/mm.c I just tested the 6.4 radeon driver and it works for me. Perhaps you just need to do a 'make realclean' and recompile.
I just tried with current XORG-CVS: 1) Original bug "running glxgears and resize window/moving window around" is fixed. 2) But now quake3 (ID or "icculus") crashs the Xserver when configured to run in fullscreen mode. It doesn't crash the Xserver if configured to run in window. If I remember correctly, this didn't happen before the fix for the original bug. 3) quake3 usually refuses to start if it detects indirect rendering, but the crash happens before quake3 decides to exit. here is a backtrace: Backtrace: 0: X(xf86SigHandler+0x7f) [0x808638f] 1: [0xffffe420] 2: /usr/X11R6/lib/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x35) [0x40472565] 3: /usr/X11R6/lib/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x63) [0x4046e903] 4: /usr/X11R6/lib/modules/extensions/libGLcore.so(__MESA_resizeBuffers+0x59) [0x4046d709] 5: /usr/X11R6/lib/modules/extensions/libglx.so(__glXResizeBuffers+0x2e) [0x402b4c2e] 6: /usr/X11R6/lib/modules/extensions/libglx.so(__glXResizeDrawableBuffers+0x5d) [0x402ba80d] 7: /usr/X11R6/lib/modules/extensions/libglx.so [0x402ba479] 8: X(compPositionWindow+0x46) [0x8156276] 9: X(ReparentWindow+0x194) [0x80d84c4] 10: X(ProcReparentWindow+0x95) [0x80c2025] 11: X(Dispatch+0x14f) [0x80c24ef] 12: X(main+0x40b) [0x80ce75b] 13: /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40088500] 14: X [0x806ff81] Fatal server error: Caught signal 11. Server aborting
I bet ctx is null in this case. This patch should do the trick: Index: drivers/x11/xm_dd.c =================================================================== RCS file: /cvs/xorg/xc/extras/Mesa/src/mesa/drivers/x11/xm_dd.c,v retrieving revision 1.1.1.4 diff -r1.1.1.4 xm_dd.c 568c568,569 < ctx->NewState |= _NEW_BUFFERS; /* to update scissor / window bounds */ --- > if (ctx) > ctx->NewState |= _NEW_BUFFERS; /* to update scissor / window bounds */ Index: main/framebuffer.c =================================================================== RCS file: /cvs/xorg/xc/extras/Mesa/src/mesa/main/framebuffer.c,v retrieving revision 1.1.1.3 diff -r1.1.1.3 framebuffer.c 312c312,313 < ctx->NewState |= _NEW_BUFFERS; --- > if (ctx) > ctx->NewState |= _NEW_BUFFERS;
yes, looks like this patch fixes the quake3 fullscreen problem. Thanks!
I've already checked the change into CVS. Closing bug report.
Created attachment 3912 [details] [review] mesa_ctx_patch.txt
It looks like the patch made it only into mesa-cvs, but not into xorg-cvs tree.
I plan to make a Mesa 6.4.1 release pretty soon. That'll go into Xorg with this fix.
Now it's in XORG CVS tree, too. Thanks!
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.