Brad King wrote: > Brian Paul wrote: >> Do those tests use the shading language? If so, could I see the shaders? >> >> Actually, pointers to the location of these programs in your CVS >> repository would be helpful. > > The actual test source is here: > > http://www.vtk.org/cgi-bin/viewcvs.cgi/Rendering/Testing/Cxx/TestOpacity.cxx?rev=1.2&view=auto > > > > I think the source you want is here: > > http://www.vtk.org/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLRenderer.cxx?rev=1.67&view=auto > > > > The variable "vtkOpenGLRenderer_PeelingFS" contains a shader program to > do "depth peeling". There is also other code in the source file that > checks for all the extensions needed to implement the shader.
OK, I'll look into that. Probably just a shading language bug. >>> The "OTHER_FAULT" ones are due to other mesa assertion failures. The >>> SEGFAULT ones seem to have some kind of memory corruption caused by >>> mesa. These failures started with changes from Feb 2 to Feb 4 in mesa. >> >> Hmmm, I don't see anything between Feb 2-4 that looks too likely. >> Could you send a stack trace from one of those failures? > > The reason I think it is mesa changes during those dates is because I > can use a Mesa from Feb 2 and nothing crashes, but when I update to Mesa > from Feb 4 with no other changes things start crashing. I tried Feb 3 > Mesa versions but they did not compile. However, I do not know much > about git so these updates were all done with git-diff piped to patch so > I do not know for sure I had the proper versions. Is there a better way > to update to a given date? Well, there's git-bisect which should narrow it down to a particular change. But I think I've fixed a problem in the osmesa driver that was causing the renderbuffer assertion. > For the OTHER_FAULT failures (mesa assertions) I can give stack traces. > For the SEGFAULT ones the stack traces all point to VTK code. My > hypothesis is that mesa is writing over some VTK memory and corrupting > it. Let's focus on the OTHER_FAULT ones for now. Here is the > OSCone-image backtrace: > > #5 0xb4611fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 > #6 0xb4609fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #7 0xb62103e4 in _mesa_reference_renderbuffer (ptr=0x82261c8, > rb=0x8226460) > at main/renderbuffer.c:2172 > #8 0xb6210569 in _mesa_add_renderbuffer (fb=0x82260a0, bufferName=0, > rb=0x8226460) at main/renderbuffer.c:2109 > #9 0xb61670bc in OSMesaMakeCurrent (osmesa=0x81eeca8, buffer=0xb3d6c008, > type=5121, width=300, height=300) at drivers/osmesa/osmesa.c:1389 > #10 0xb66decef in vtkXOpenGLRenderWindow::MakeCurrent (this=0x81d3d50) > at /home/kitware/Dashboards/My > Tests/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1255 > > The assertion failure that called abort was: > > main/renderbuffer.c:2172: _mesa_reference_renderbuffer: Assertion > `rb->Magic == 0xaabbccdd' failed. Let me know how things look with the above-mentioned change. -Brian ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
