On 08/06/2010 05:20 PM, tom fogal wrote:
>
> 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 l
On 08/11/2010 11:55 PM, tom fogal wrote:
> Dan Nicholson writes:
> [snip]
>
>> So, sorry for not reading the whole thread, but is GL being linked
>> because it's needed by the app, because pkg-config said so, or
>> because the linker added it?
>>
> It's needed by the app. Not really, it's
Dan Nicholson writes:
[snip]
> So, sorry for not reading the whole thread, but is GL being linked
> because it's needed by the app, because pkg-config said so, or
> because the linker added it?
It's needed by the app. Not really, it's not used at runtime, but
needed at link time because the app
On Fri, Aug 6, 2010 at 2:20 PM, tom fogal wrote:
> "Kevin H. Hobbs" 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 ou
On 08/10/2010 04:44 PM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>>
>> VTK_USE_X:BOOL=ON is set the test segfaults.
>
> What does VTK_USE_X change/end up doing?
>
Most of the action seems to happen in Rendering/CMakeLists.txt where on
linux with VTK_USE_X=ON :
vtkXGPUInfoList.cxx is added
"Kevin H. Hobbs" writes:
> On 08/10/2010 02:47 PM, Kevin H. Hobbs wrote:
> With VTK_USE_X:BOOL=OFF the test also passes with libGL.so and
> libOSMesa.so switched that is
>
> VTK_USE_X:BOOL=OFF
> OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so
> OSMESA_LIBRARY:FILEPATH=/home/kevin/mes
On 08/10/2010 02:47 PM, Kevin H. Hobbs wrote:
>
> VTK_USE_X:BOOL=OFF
>
With VTK_USE_X:BOOL=OFF the test also passes with libGL.so and
libOSMesa.so switched that is
VTK_USE_X:BOOL=OFF
OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so
OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.
On 08/06/2010 05:20 PM, tom fogal wrote:
> 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 libO
Although the backtrace after the segfault does not show other functions
between vtkOpenGLRenderWindow::OpenGLInit and vbo_exec_EvalCoord1fv I am
able to set a breakpoint at vtkOpenGLRenderWindow::OpenGLInit and step
through the program. I can see the execution moving through mesa
functions. I'm onl
On 08/06/2010 05:20 PM, tom fogal wrote:
>
> 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.
>
"Kevin H. Hobbs" 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 eas
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
On 08/06/2010 10:47 AM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>>
>> my git bisect script uses :
>>
>> make -j8 linux-x86-64-debug
>>
>> so -fvisibility=3Dhidden is not added to the command line of the
>> builds in the git bisection.
>
> Oh. Can you add it into your bisect script and try
On 08/05/2010 06:50 PM, Brian Paul wrote:
>
> Kevin, you seem to have identified two potential commits that caused
> trouble:
>
> 91c37599f621a0ec498c0f0add14f16470ca852b
> and
> 36b3a8bd5a317ab297f44b19fd14c7e76ec2fc77
>
> You should go to the head of the Mesa git tree and then undo each of
> t
"Kevin H. Hobbs" writes:
> On 08/05/2010 07:07 PM, tom fogal wrote:
> > Brian Paul writes:
> >> My other hunch is something is duplicated in the libOSMesa and libGL
> >> libraries that's causing things to blow up in general.
> >>
> > Do note that both of these issues are from the
> > pre-"-fvisib
"Kevin H. Hobbs" writes:
> On 08/05/2010 06:30 PM, tom fogal wrote:
> > Is your test multithreaded, by any chance?
>
> I can't really answer this : it's VTK's test.
>
> When I run the test in gdb it tells me :
>
> [Thread debugging using libthread_db enabled]
No, then; you'd see:
[New Threa
On 08/05/2010 06:30 PM, tom fogal wrote:
>
>
> Is your test multithreaded, by any chance?
>
I can't really answer this : it's VTK's test.
When I run the test in gdb it tells me :
[Thread debugging using libthread_db enabled]
and when I quit from gdb gdb warns me that :
A debugging session i
On 08/05/2010 07:07 PM, tom fogal wrote:
> Brian Paul writes:
> [snip]
>
>> My other hunch is something is duplicated in the libOSMesa and libGL
>> libraries that's causing things to blow up in general.
>>
> Do note that both of these issues are from the pre-"-fvisibility=hidden
> by defau
Brian Paul writes:
[snip]
> My other hunch is something is duplicated in the libOSMesa and libGL
> libraries that's causing things to blow up in general.
This is a good hunch.
I don't know how closely you've been following the thread, Brian, but
previously I brought up how it was important that
On 08/05/2010 04:30 PM, tom fogal wrote:
"Kevin H. Hobbs" writes:
On 08/04/2010 05:58 PM, tom fogal wrote:
If you can find the commit that started the trouble (using git
bisect), that might shed some light.
With my script adjusted to only report when the test started
segfaulting git bisect r
"Kevin H. Hobbs" writes:
> On 08/04/2010 05:58 PM, tom fogal wrote:
> > If you can find the commit that started the trouble (using git
> > bisect), that might shed some light.
>
> With my script adjusted to only report when the test started
> segfaulting git bisect reports :
>
> 91c37599f621a0ec4
On 08/04/2010 05:58 PM, tom fogal wrote:
> If you can find the commit that started the trouble (using git bisect),
> that might shed some light.
>
With my script adjusted to only report when the test started segfaulting
git bisect reports :
91c37599f621a0ec498c0f0add14f16470ca852b is the first
On 08/04/2010 05:58 PM, tom fogal wrote:
>
> If you can find the commit that started the trouble (using git bisect),
> that might shed some light.
>
I ran :
git bisect start
git bisect bad
git bisect good mesa_7_6
git bisect run ~/kitware/os_bisect_script.sh
The os_bisect_script.sh s
"Kevin H. Hobbs" writes:
> On 08/04/2010 04:21 PM, tom fogal wrote:
> >
> > Can you try valgrind? Perhaps somehow the generated dispatch
> > code is jumping into lalaland and somehow magically ends up in
> > vbo_exec_EvalCoord1fv (pretty far-fetched, but I'm out of ideas
> > here...).
>
> valgrin
On 08/04/2010 04:21 PM, tom fogal wrote:
>
> Can you try valgrind? Perhaps somehow the generated dispatch
> code is jumping into lalaland and somehow magically ends up in
> vbo_exec_EvalCoord1fv (pretty far-fetched, but I'm out of ideas
> here...).
>
valgrind suggested I add --leak-check=full
On 08/04/2010 04:21 PM, tom fogal wrote:
>
> I am not sure what is wrong here, but something is.
> vbo_exec_EvalCoord1fv and vbo_exec_EvalCoord1f are both static methods
> in that file... there is no way OpenGLInit could call them. They must
> be called automagically during OSMesaCreateContext or
On 08/04/2010 03:29 PM, tom fogal wrote:
>
> To workaround it, we tell VTK that the OpenGL library is OSMesa and the
> OSMesa library is libGL. I would test that the above workaround works
> (i.e. you're hitting the same issue I did) before filing a bug.
>
> -tom
>
With the the mesa libraries
"Kevin H. Hobbs" writes:
> On 08/04/2010 03:01 PM, tom fogal wrote:
> >
> > 3) Doesn't seem likely that ::OpenGLInit calls
> > vbo_exec_EvalCoord1fv :) Are you missing debug symbols in Mesa?
> > Could you get a stack trace w/ full debug symbols?
>
[snip]
> Program received signal SIGSEGV, Segmenta
On 08/04/2010 03:01 PM, tom fogal wrote:
>
> 3) Doesn't seem likely that ::OpenGLInit calls vbo_exec_EvalCoord1fv :)
> Are you missing debug symbols in Mesa? Could you get a stack trace w/
> full debug symbols?
>
The full gdb session with both mesa and VTK built with debug symbols is :
$ gdb
"Kevin H. Hobbs" writes:
> On 08/04/2010 03:01 PM, tom fogal wrote:
> > 2) Make sure to switch the Mesa libraries in VTK's CMake step. The
> > critical component is that your link lines must put "OSMesa" and
> > "MesaGL" in the 'correct' ordering, where 'correct' depends on
> > which you want to
On 08/04/2010 03:01 PM, tom fogal wrote:
>
> No "--enable-gl-osmesa" ?
>
>
That's right I do not have "--enable-gl-osmesa". according to "configure
--help" this is on by default when the xlib driver is used.
> 1) Make sure you've got -fvisibility=hidden when you're building;
> the VBO code s
"Kevin H. Hobbs" writes:
> building mesa with:
>
> ./autogen.sh \
> --with-driver=3Dxlib \
> --disable-gallium \
> --without-demos
> make
No "--enable-gl-osmesa" ?
> It was also at this time that libOSMesa went from being linked
> against libGL to being linked to mesa internal static li
I'm looking into some segfaults in VTK's Offscreen tests.
These failures appeared about the time that I switched from building
mesa with the "make linux-x86-64" target and moved to buiulding mesa with :
./autogen.sh \
--with-driver=xlib \
--disable-gallium \
--without-demos
make
It was al
33 matches
Mail list logo
