[vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder

[Andrew Maclean]

Sean,
   Thankyou for this information! I have been trying to
convert TestEmptyInput.tcl to python and have been getting random hangs in
windows, now I know the cause!
Currently I can test 1708 classes out of 1981 classes.
This is done by removing the testing for vtkDataEncoder, and filtering out
classes that have 'Reader', 'Writer', 'Array_I', 'Qt' in their names. and
trapping abstract classes and those such as vtkMathTextUtilities which have
no concrete implementation. I am also skipping the classExcepions as
detailed in the tcl code.

I am not sure if this is a good approach, but I think I am getting there.

I am also adding an observer for error events but it has only picked up a
fail on:
144  Testing -- vtkObjectBase -
vtkObjectBase AddObserver

Also there is a message like:
221  Testing -- vtkStreamingStatistics -
StatisticsAlgorithm not set! Punting!
Not sure what to do with this one.


Regards
   Andrew

---------- Forwarded message ----------
> From: Sean McBride <sean at rogue-research.com>
> To: <vtk-developers at vtk.org>
> Cc:
> Date: Mon, 30 Mar 2015 17:32:09 -0400
> Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to
> use-after-free in vtkDataEncoder
> Hi all,
>
> On my Rogue7 dashboard vtkCommonCoreTcl-TestEmptyInput fails
> intermittently.
>
> I debugged it a bit and, long story short, the evidence suggested a
> use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to freed
> memory) and caught it in lldb:
>
> (lldb) bt
> * thread #7: tid = 0x64d84d, 0x00007fff8a7afbc9
> libsystem_c.dylib`pthread_mutex_lock + 20, stop reason = EXC_BAD_ACCESS
> (code=EXC_I386_GPFLT)
>     frame #0: 0x00007fff8a7afbc9 libsystem_c.dylib`pthread_mutex_lock + 20
>     frame #1: 0x0000000100fd0e3e
> libvtkCommonCore-6.3.1.dylib`vtkSimpleMutexLock::Lock(this=0x555555555555561d)
> + 94 at vtkMutexLock.cxx:75
>     frame #2: 0x000000013886bd3e libvtkWebCore-6.3.1.dylib`(anonymous
> namespace)::vtkSharedData::BeginWorker(this=0x5555555555555555) + 158 at
> vtkDataEncoder.cxx:99
>     frame #3: 0x000000013886ad18 libvtkWebCore-6.3.1.dylib`(anonymous
> namespace)::Worker(calldata=0x000000010f046740) + 248 at
> vtkDataEncoder.cxx:304
>     frame #4: 0x00007fff8a7aa772 libsystem_c.dylib`_pthread_start + 327
>     frame #5: 0x00007fff8a7971a1 libsystem_c.dylib`thread_start + 13
>
> Notice the this=0x5555555555555555.  Definitely use-after-free.
>
> Hopefully this is enough for someone that knows this code to squash the
> bug...!
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ben Boeckel <ben.boeckel at kitware.com>
> To: Sean McBride <sean at rogue-research.com>
> Cc: vtk-developers at vtk.org
> Date: Mon, 30 Mar 2015 18:05:49 -0400
> Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due
> to use-after-free in vtkDataEncoder
> On Mon, Mar 30, 2015 at 17:32:09 -0400, Sean McBride wrote:
> > I debugged it a bit and, long story short, the evidence suggested a
> > use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to
> > freed memory) and caught it in lldb:
>
> FWIW, same thing with glibc:
>
>     export MALLOC_PERTURB_=100
>
> Any value between 1 and 255 will memset() inside of free() (0 disables).
> Causes ~5% overhead or so.
>
> --Ben
>
>
>
> ---------- Forwarded message ----------
> From: Sean McBride <sean at rogue-research.com>
> To: <ben.boeckel at kitware.com>
> Cc: vtk-developers at vtk.org
> Date: Mon, 30 Mar 2015 18:30:49 -0400
> Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due
> to use-after-free in vtkDataEncoder
> On Mon, 30 Mar 2015 18:05:49 -0400, Ben Boeckel said:
>
> >> I debugged it a bit and, long story short, the evidence suggested a
> >> use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to
> >> freed memory) and caught it in lldb:
> >
> >FWIW, same thing with glibc:
> >
> >    export MALLOC_PERTURB_=100
> >
> >Any value between 1 and 255 will memset() inside of free() (0 disables).
> >Causes ~5% overhead or so.
>
> The OS X one has similarly low overhead, and as such has been enabled on
> all my dashboards for ages.
>
> Getting off-topic I guess, but given the low overhead and great benefit,
> would be nice to have it enabled on the continuous and gitlab bots too...
> (maybe it is?)
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ben Boeckel <ben.boeckel at kitware.com>
> To: Sean McBride <sean at rogue-research.com>
> Cc: vtk-developers at vtk.org
> Date: Mon, 30 Mar 2015 22:34:52 -0400
> Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due
> to use-after-free in vtkDataEncoder
> On Mon, Mar 30, 2015 at 18:30:49 -0400, Sean McBride wrote:
> > The OS X one has similarly low overhead, and as such has been enabled
> > on all my dashboards for ages.
>
> How is it enabled? Environment? Or is it special tooling?
>
> > Getting off-topic I guess, but given the low overhead and great
> > benefit, would be nice to have it enabled on the continuous and gitlab
> > bots too... (maybe it is?)
>
> I'll start turning it on for them. Since we'd like to keep things green,
> we it won't be a one-shot deal. In front of that though is doing
> parallel testing (shaves ~hour off of some builds so our turn-around
> should be much better).
>
> --Ben
>



> --
>
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150331/28cae5f3/attachment.html>