[Mesa-dev] OSMesa VTK Test Segfault

Brian Paul brianp at vmware.com
Tue Oct 26 08:34:22 PDT 2010


On 10/25/2010 12:26 PM, Kevin H. Hobbs wrote:
> I build VTK from git with Mesa from git every night.
>
> mesa is built with :
>
> ./autogen.sh \
>    --prefix=/home/kevin/mesa_osmesa/ \
>    --with-driver=osmesa \
>    --disable-gallium
>
> VTK is linked to OSMesa only and no other GL.
>
> VTK's Charts-TestMultipleScalarsToColors test is segfaulting.
>
> The backtrace from gdb is :
>
> #0  glGetString () at glapi_x86-64.S:9876
> #1  0x00007ffff6031cd7 in vtkOpenGLExtensionManager::ExtensionSupported
> (this=0x654b50, name=0x41d7f6 "GL_VERSION_1_2")
>      at /home/kevin/kitware/VTK/Rendering/vtkOpenGLExtensionManager.cxx:204
> #2  0x00000000004162d5 in TestMultipleScalarsToColors ()
>      at
> /home/kevin/kitware/VTK/Charts/Testing/Cxx/TestMultipleScalarsToColors.cxx:47
> #3  0x000000000040e5db in main (ac=9, av=0x7fffffffdb00)
>      at
> /home/kevin/kitware/VTK_OSMesa_Build/Charts/Testing/Cxx/ChartsCxxTests.cxx:288
>
> The output from valgrind is :
>
> $ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/ChartsCxxTests
> "TestMultipleScalarsToColors" "-D" "/home/kevin/kitware/VTKData" "-T"
> "/home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary" "-V"
> "Baseline/Charts/TestMultipleScalarsToColors.png" "-E" "25"
> ==28040== Memcheck, a memory error detector
> ==28040== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==28040== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> ==28040== Command:
> /home/kevin/kitware/VTK_OSMesa_Build/bin/ChartsCxxTests
> TestMultipleScalarsToColors -D /home/kevin/kitware/VTKData -T
> /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary -V
> Baseline/Charts/TestMultipleScalarsToColors.png -E 25
> ==28040==
> ==28040== Invalid read of size 8
> ==28040==    at 0xB571A07: glGetString (glapi_x86-64.S:9876)
> ==28040==    by 0x4162D4: TestMultipleScalarsToColors(int, char**)
> (TestMultipleScalarsToColors.cxx:47)
> ==28040==    by 0x40E5DA: main (ChartsCxxTests.cxx:288)
> ==28040==  Address 0x898 is not stack'd, malloc'd or (recently) free'd
> ==28040==
> ==28040==
> ==28040== Process terminating with default action of signal 11 (SIGSEGV)
> ==28040==  Access not within mapped region at address 0x898
> ==28040==    at 0xB571A07: glGetString (glapi_x86-64.S:9876)
> ==28040==    by 0x4162D4: TestMultipleScalarsToColors(int, char**)
> (TestMultipleScalarsToColors.cxx:47)
> ==28040==    by 0x40E5DA: main (ChartsCxxTests.cxx:288)
> ==28040==  If you believe this happened as a result of a stack
> ==28040==  overflow in your program's main thread (unlikely but
> ==28040==  possible), you can try to increase the size of the
> ==28040==  main thread stack using the --main-stacksize= flag.
> ==28040==  The main thread stack size used in this run was 10485760.
> ==28040== Invalid free() / delete / delete[]
> ==28040==    at 0x4A04D72: free (vg_replace_malloc.c:325)
> ==28040==    by 0x318532735A: ??? (in /lib64/libc-2.11.2.so)
> ==28040==    by 0x3185326EF1: ??? (in /lib64/libc-2.11.2.so)
> ==28040==    by 0x480162B: _vgnU_freeres (vg_preloaded.c:62)
> ==28040==    by 0x6AC9CD6:
> vtkOpenGLExtensionManager::ExtensionSupported(char const*)
> (vtkOpenGLExtensionManager.cxx:204)
> ==28040==    by 0x4162D4: TestMultipleScalarsToColors(int, char**)
> (TestMultipleScalarsToColors.cxx:47)
> ==28040==    by 0x40E5DA: main (ChartsCxxTests.cxx:288)
> ==28040==  Address 0xb38ca10 is not stack'd, malloc'd or (recently) free'd
> ==28040==
> ==28040==
> ==28040== HEAP SUMMARY:
> ==28040==     in use at exit: 168,234 bytes in 1,731 blocks
> ==28040==   total heap usage: 1,806 allocs, 77 frees, 189,825 bytes
> allocated
> ==28040==
> ==28040== LEAK SUMMARY:
> ==28040==    definitely lost: 0 bytes in 0 blocks
> ==28040==    indirectly lost: 0 bytes in 0 blocks
> ==28040==      possibly lost: 10,645 bytes in 112 blocks
> ==28040==    still reachable: 157,589 bytes in 1,619 blocks
> ==28040==         suppressed: 0 bytes in 0 blocks
> ==28040== Rerun with --leak-check=full to see details of leaked memory
> ==28040==
> ==28040== For counts of detected and suppressed errors, rerun with: -v
> ==28040== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 6 from 6)
> Segmentation fault
>
> Could this be a problem in Mesa?

Hmmm, can you try using an older version from git and see if it's a 
regression?

-Brian



More information about the mesa-dev mailing list