On 08/12/2013 10:29 AM, Brian Paul wrote:
> On 08/09/2013 01:50 PM, Kevin H. Hobbs wrote:
>> (gdb) print pstip
>> $1 = (struct pstip_stage *) 0xff66331aff66331a
>>
>> I don't think my actual RAM goes that high.
>
> That looks suspect since the low and high halves of the address are the
> same.
>
On 08/13/2013 01:41 PM, Kevin H. Hobbs wrote:
>
> Ha! I can move the segfault all the way back to :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe0ba6d43 in osmesa_st_framebuffer_flush_front
> (stctx=0x1518ee0, stfbi=0x1520560,
> statt=ST_ATTACHMENT_FRONT_LEFT) at osme
On 08/13/2013 11:45 AM, Kevin H. Hobbs wrote:
> On 08/13/2013 09:50 AM, Brian Paul wrote:
>> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>>
>>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV)
>>> - exiting
>>>
>> Well, that's not too helpful.
>
Ha! I can move the se
On 08/13/2013 09:50 AM, Brian Paul wrote:
> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>
>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
>> exiting
>>
> Well, that's not too helpful.
I think it may have been helpful.
Before Valgrind crashed it mentions that
On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
On 08/12/2013 10:29 AM, Brian Paul wrote:
Can you run with valgrind? That should give us some useful info if
there's a use-after-free.
Sure,
$ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython
"--enable-bt"
"/home/kevin/kitware/VTK_OSMe
On 08/12/2013 10:29 AM, Brian Paul wrote:
> Can you run with valgrind? That should give us some useful info if
> there's a use-after-free.
Sure,
$ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython
"--enable-bt"
"/home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py/rtImageTest.
On 08/09/2013 01:50 PM, Kevin H. Hobbs wrote:
On 08/09/2013 01:59 PM, Brian Paul wrote:
That's probably not it, given the above. Can you try setting a
breakpoint on pstip_destroy() and see if that's getting called before
the segfault? If so, things are getting freed in the wrong order.
No,
On 08/09/2013 01:59 PM, Brian Paul wrote:
>
> That's probably not it, given the above. Can you try setting a
> breakpoint on pstip_destroy() and see if that's getting called before
> the segfault? If so, things are getting freed in the wrong order.
>
No, it is not called before the segfault.
On 08/09/2013 11:53 AM, Kevin H. Hobbs wrote:
On 08/09/2013 09:16 AM, Brian Paul wrote:
On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
Hmm, I'd expect memcpy() of length zero to be fine even if src/dst
On 08/09/2013 09:16 AM, Brian Paul wrote:
> On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
>>
>> #0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
>> at draw/draw_pipe_pstipple.c:713
>>
> Hmm, I'd expect memcpy() of length zero to be fine even if src/dst were
> null.
>
memcpy is fine, t
On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes
OSMesa segfault.
This is the top of the gdb backtrace :
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf7580fc in cso_rel
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes
OSMesa segfault.
This is the top of the gdb backtrace :
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf7580fc in cso_release_all (ctx=ctx@entry=0x15f1540) at
cso_cache/
12 matches
Mail list logo
