Lionel Ulmer wrote:
>
> Hi all,
>
> I found this bug while trying the GLX module for my TNT2 when it froze
> my X server.
>
> After some investigation, I found out that the problem lies in Mesa
> (CVS as of 09/30, compiled with debug informations and with only the X
> driver).
>
> (gdb) r
> Starting program: /usr/local/src/Mesa/Tests/testGL2
> GenuineIntel cpu detected.
>
> Program received signal SIGSEGV, Segmentation fault.
> gl_compute_orflag (IM=0x81cdae0) at vbxform.c:457
> 457 andflag &= IM->Flag[i];
> (gdb) bt
> #0 gl_compute_orflag (IM=0x81cdae0) at vbxform.c:457
> #1 0x8123024 in gl_maybe_transform_vb (IM=0x81cdae0) at vbxform.c:65
> #2 0x8123082 in gl_flush_vb (ctx=0x81b28f8, where=0x819c9d0 "glMatrixMode") at
>vbxform.c:89
> #3 0x80b3db5 in gl_MatrixMode (ctx=0x81b28f8, mode=GL_MODELVIEW) at matrix.c:989
> #4 0x804d466 in glMatrixMode (mode=GL_MODELVIEW) at api1.c:1957
> #5 0x8049d22 in main ()
> (gdb) p count
> $1 = 135983552
>
> The program is attached to this mail. It's not very important for me
> that this bug is found as this program is really just an old glX
> program, but you may find this interesting :-)
>
> As I find the vertex buffer / transform code rather opaque, I did not
> try to debug it further than looking a bit at the code for 'stupid'
> errors.
The problem was actually a memory management issue in GL_COMPILE_AND_EXECUTE.
Memory was freed but still used - the next person to malloc() that bit of memory
was somewhere in the Xlib event handling code, probably queuing up your mouse
clicks. When the memory was incorrectly referenced again from mesa, you got the
confusing bug you describe.
This should be fixed now - have another try...
Keith
_______________________________________________
Mesa-bug maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-bug
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
