Bug 4087

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!