Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=512
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dri-
| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2004-03-04 14:15 -------
(In reply to comment #33)
> OK, MALLOC_CHECK_ did the trick. I've found a problem in GL/glx/single2.c it
> looks like we're malloc'ing 1 less byte than we really need:
>
> I did:
>
> --- single2.c.org 2004-03-04 10:43:11.000000000 -0700
> +++ single2.c 2004-03-04 09:56:39.000000000 -0700
> @@ -344,7 +344,7 @@
> if ( atof( string ) > atof( GLServerVersion ) ) {
> buf = __glXMalloc( __glXStrlen( string )
> + __glXStrlen( GLServerVersion )
> - + 3 );
> + + 4 );
> if ( buf == NULL ) {
> string = GLServerVersion;
> }
>
> And it now does not segfault in that location.
Good one! I'll commit that fix now.
Maybe someone on a Mesa list or on the [EMAIL PROTECTED] list
could look at this and see if something is going wrong higher up, or whether the
NULL checks simply need to be added.
> Now, believe it or not, I have a third segfault happening in the same application!
>
> Backtrace looks like this:
> Program received signal SIGSEGV, Segmentation fault.
> 0x095e2982 in clear_16bit_ximage (ctx=0x9b13d20, all=1 '\001', x=0, y=0,
> width=0, height=0) at xm_dd.c:387
> 387 register GLuint *ptr4 = (GLuint *)
> xmesa->xm_draw_buffer->backimage->data;
> (gdb) bt
> #0 0x095e2982 in clear_16bit_ximage (ctx=0x9b13d20, all=1 '\001', x=0, y=0,
> width=0, height=0)
> at xm_dd.c:387
> #1 0x095e31c0 in clear_buffers (ctx=0x9b13d20, mask=4, all=1 '\001', x=0, y=0,
> width=0, height=0)
> at xm_dd.c:722
> #2 0x091fc04a in _mesa_Clear (mask=16384) at buffers.c:135
> #3 0x09335c49 in glClear (mask=16640) at glapitemp.h:1078
> #4 0x0929667d in __glXDisp_Clear (pc=0x98f5f70 "") at g_render.c:1236
> #5 0x0927cff5 in __glXRender (cl=0x98b1d38, pc=0x98f5f6c "\b") at glxcmds.c:1320
> #6 0x09284489 in __glXDispatch (client=0x98b17f0) at glxext.c:434
> #7 0x080cd50d in Dispatch () at dispatch.c:446
> #8 0x080e3548 in main (argc=2, argv=0xbff04434, envp=0xbff04440) at main.c:432
> #9 0x00b81770 in __libc_start_main () from /lib/tls/libc.so.6
>
> at xm_dd.c:387, there is a reference to backimage. At line 387 in the debugger,
> I see that this is 0:
>
> 387 register GLuint *ptr4 = (GLuint *)
> xmesa->xm_draw_buffer->backimage->data;
> (gdb) print xmesa
> $1 = 0x91a80f0
> (gdb) print xmesa->xm_draw_buffer
> $2 = 0xbbcd0008
> (gdb) print xmesa->xm_draw_buffer->backimage
> $3 = (XMesaImage *) 0x0
>
> The indexing of ->data off a null pointer is crashing. This looks like what I
> was dealing with in comment #20.
>
> Apparently, something about this application is causing backimage and/or
> backpixmap to be null rather than containing valid data.
>
> Is there someone who knows a good place further up in the logic to solve this
> rather than having to hunt down every reference and check for valid pointers? I
> understand the C code, but I don't really understand what the larger logic is
> doing with these structures.
>
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
