[Mesa-dev] VTK Offscreen Segfaults

[tom fogal]

"Kevin H. Hobbs" <hobbsk at ohiou.edu> writes:
> On 08/06/2010 03:15 PM, tom fogal wrote:
> > If you could build VTK with just a single GL library -- i.e. with
> > just libOSMesa or just libGL, but not both -- and could reproduce
> > the crash,= that would rule out my symbol collision theory.  I am
> > not sure how easy= that is, though...
> 
> That was shockingly easy... sort of.
> 
> I did my VTK build with both
> 
> -DOPENGL_gl_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
> -DOSMESA_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
> 
> and I left off -fvisibility=3Dhidden thinking that I want the symbols
> that are now included in libOSMesa.so to be available to VTK.

Nah, the visibility thing only hides symbols that should be hidden
anyway; i.e. the vbo symbols and the like. gl* will always be available
regardless of the -fvisibility setting and regardless of which library
is being built/used.

> and what do you know the test passed.

Great!

> however I wanted to see if VTK is really built with only libOSMesa.so
> so I did :
>
>  $ ldd ../VTK_Build/bin/RenderingCxxTests | grep mesa  libOSMesa.so.7 =>
>  /tmp/mesa/lib64/libOSMesa.so.7 (0x00007fa97ff4a000)  libGL.so.1 =>
>  /tmp/mesa/lib64/libGL.so.1 (0x00007fa97bc7a000)
>
> so it got pulled in somehow perhaps by libOSMesa.so itself?
>
> If I do :
>
> $ ldd ../mesa/lib64/libOSMesa.so | grep libGL.so
>   libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007f88ed2cf000)
>
> because libOSMesa.so needs libGL.so and I have the nvidia drivers in
> my dynamic linker path but VTK has an rpath set so...

Yeah... hrm, I thought Dan's change got rid of that, but maybe I
misunderstood it.

Could you rm /tmp/mesa/lib64/libGL.so* before building VTK?  My hunch
is that VTK is linking it in anyway; maybe it stuck around in cmake's
cache or something.

> What does all of this mean?

Well, it does appear to be some type of symbol resolution/overloading
issue.  However it seems to be with internal Mesa symbols.  Switching
to a single library -- that is, putting OSMesaCreateContext, etc. into
libGL directly, and getting rid of libOSMesa altogether -- seems like
it would be the solution, but I imagine there's some reason that's not
happening already.

Let's ping Dan (added to the CC list), he knows more about this kind
of thing than I do.  Dan, have you been following this thread?  The
working theory is that there is a symbol in both libOSMesa and libGL.
Something about the symbol existing in both is causing Badness during
linking; seemingly innocuous changes cause Kevin's test program to
jump into odd parts of Mesa (e.g. VBO code while doing initial matrix
setup).  The issue appears to be with internal symbols, but hidden
symbol visibility isn't helping.

-tom