Re: [Mesa3d-dev] Recent refactoring broke VTK

[Brad K. <bra...@ki...>]

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 <ke...@tu...>
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