Brad King wrote:
> Brad King wrote:
>> Brian Paul wrote:
>>> Brad, the first thing that'd be useful is a stack trace from the crash 
>>> point.
>> Oops, of course.  I had been collecting pieces of information before
>> sending the email and never cut-and-paste it in.  Here is the assertion
>> failure stack trace:
>>
>> #0  0x00002adc747e11d5 in raise () from /lib/libc.so.6
>> #1  0x00002adc747e2680 in abort () from /lib/libc.so.6
>> #2  0x00002adc747da75f in __assert_fail () from /lib/libc.so.6
>> #3  0x00002adc72a01c1f in _mesa_HashLookup (table=<value optimized out>,
>> key=<value optimized out>) at main/hash.c:133
>> #4  0x00002adc72a38c6d in _mesa_DeleteTextures (n=1,
>> textures=0x7fff3d22a208) at main/texobj.c:803
>> #5  0x00002adc6ddf5c2f in (VTK Code)
> 
> More recently published changes have broken VTK further:
> 
> http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=180467
> 
> I chose the "contoursToSurfacePython" test to track things down this time:
> 
> http://www.cdash.org/CDash/testDetails.php?test=9894872&build=180467
> 
> Test output includes:
> -----------------------------------------------------------------------------
> *** glibc detected *** /.../bin/vtkpython: double free or corruption (!prev): 
> 0x0000000001224b00 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2b09530c001d]
> /lib/libc.so.6(cfree+0x76)[0x2b09530c1d26]
> /...lib/libMesaGL.so.1(_mesa_delete_buffer_object+0x12)[0x2b094f56f942]
> /.../lib/libMesaGL.so.1(_mesa_free_context_data+0x107)[0x2b094f571657]
> /.../lib/libMesaGL.so.1(XMesaDestroyContext+0x29)[0x2b094f52dbf9]
> /.../Mesa-build/lib/libMesaGL.so.1[0x2b094f521884]
> (VTK code)...
> -----------------------------------------------------------------------------
> 
> A backtrace in gdb gives:
> -----------------------------------------------------------------------------
> #0  0x00002b6991bd91d5 in raise () from /lib/libc.so.6
> #1  0x00002b6991bda680 in abort () from /lib/libc.so.6
> #2  0x00002b6991c11f4b in __libc_message () from /lib/libc.so.6
> #3  0x00002b6991c1701d in malloc_printerr () from /lib/libc.so.6
> #4  0x00002b6991c18d26 in free () from /lib/libc.so.6
> #5  0x00002b698ef4b942 in _mesa_delete_buffer_object (ctx=<value optimized 
> out>, bufObj=0xa72dd0) at main/bufferobj.c:168
> #6  0x00002b698ef4d657 in _mesa_free_context_data (ctx=0xa7d3c0) at 
> main/context.c:1336
> #7  0x00002b698ef09bf9 in XMesaDestroyContext (c=0xa7d3c0) at xm_api.c:1657
> #8  0x00002b698eefd884 in Fake_glXDestroyContext (dpy=<value optimized out>, 
> ctx=0x23bf) at fakeglx.c:1654
> #9  0x00002b698b8136fb in (VTK code)
> -----------------------------------------------------------------------------
> 
> git bisect reports:
> -----------------------------------------------------------------------------
> 33fef8be825ee8ec6abc0c2ffd9a3a967d84df88 is first bad commit
> commit 33fef8be825ee8ec6abc0c2ffd9a3a967d84df88
> Author: Keith Whitwell <[EMAIL PROTECTED]>
> Date:   Tue Dec 18 16:56:22 2007 +0000
> 
>     vbo: unmap and remap immediate vbo before/after each draw.
> 
>     Also use BufferData(NULL) to get fresh storage and avoid synchronous
>     operation where we would have to flush and wait for the fence after each
>     draw because of the map.
> 
>     This will chew through a whole load of buffer space on small draws, so
>     it isn't a proper solution.  Need to support a no-fence or append mapping
>     mode to do this right, or use user buffers.
> -----------------------------------------------------------------------------

Brad, I've committed a fix that should solve this later problem.

For the first issue (_mesa_HashLookup), it would be helpful if there was 
debug info in the stack trace.

-Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to