[vtk-developers] Need help with a crash on Kamino OSX Release mode.

Andrew Maclean andrew.amaclean at gmail.com
Fri May 1 16:02:25 EDT 2015


That would be perfect, thanks.
On 01/05/2015 11:17 PM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com>
wrote:

> Andrew,
>
> I can look at it over the weekend. Would that work?
>
> Utkarsh
>
> On Fri, May 1, 2015 at 1:20 AM, Andrew Maclean
> <andrew.amaclean at gmail.com> wrote:
> > I am wondering whether tbb may be picking up something. Kamino is the
> only
> > machine with tbb and it is the only one generating this error,
> unfortunately
> > it runs in release mode:
> >
> > Process id 46048 Caught SIGSEGV at 0x0 address not mapped to object
> > Program Stack:
> > WARNING: The stack trace will not use advanced capabilities because this
> is
> > a release build.
> > 0x7fff87b7acfa : _sigtramp [(libsystem_c.dylib) ???:-1]
> > 0x2 : ??? [(???) ???:-1]
> > 0x10f5e8f68 : _ZL27PyvtkView_SetRepresentationP7_objectS0_
> > [(libvtkViewsCorePython27D-6.3.1.dylib) ???:-1]
> >
> > Has someone got a debug build similar to Kamino using tbb?
> > If so I would really appreciate it if they could run this code on it.
> >
> > To reiterate it is the following merge request:
> > https://gitlab.kitware.com/vtk/vtk/merge_requests/151
> >
> > Thanks
> >    Andrew
> >
> >
> > On Thu, Apr 30, 2015 at 10:09 AM, Andrew Maclean <
> andrew.amaclean at gmail.com>
> > wrote:
> >>
> >> Hi David,
> >>    Thanks for this.
> >> I have just added vtkScatterPlotMatrix along with vtkChartMatrix back,
> >> oddly enough my windows machine never picked it up but one of the linux
> >> buildbots did once. Then I took it out and everything seemed ok, it's
> back
> >> in now.
> >>
> >> I totally agree with you over the usefulness of Debug Visual Studio! It
> is
> >> my main bug catcher. I use a little utility called Path Editor to
> reorder
> >> the release and debug lib and bin paths in the environment variables
> >> (PYTHONPATH and PATH).
> >>
> >> Regards
> >>     Andrew
> >>
> >> On Wed, Apr 29, 2015 at 10:57 PM, David Cole <DLRdave at aol.com> wrote:
> >>>
> >>> The call stack for the out of range subscript assertion is:
> >>>
> >>>   msvcp120d.dll!00007fff4d2765d6() Unknown
> >>>
> >>>
> vtkChartsCore-6.3.dll!std::vector<vtkSmartPointer<vtkChart>,std::allocator<vtkSmartPointer<vtkChart>
> >>> > >::operator[](unsigned __int64 _Pos) Line 1202 C++
> >>>   vtkChartsCore-6.3.dll!vtkChartMatrix::GetChart(const vtkVector2i &
> >>> position) Line 223 C++
> >>>   vtkChartsCore-6.3.dll!vtkScatterPlotMatrix::SetActivePlot(const
> >>> vtkVector2i & pos) Line 402 C++
> >>> >
> >>> >
> vtkChartsCorePython27D-6.3.dll!PyvtkScatterPlotMatrix_SetActivePlot(_object
> >>> > * self, _object * args) Line 213 C++
> >>>   python27.dll!000000001e0c2199() Unknown
> >>>
> >>> Looks like vtkScatterPlotMatrix_SetActivePlot can't be called from
> >>> this test because other stuff that it depends on for proper operation
> >>> is not usable as-initialized. This indicates to me that it may only be
> >>> luck when it succeeds on non-VS-Debug builds, since the uninitialized
> >>> variables, assuming that's what the cause is, will contain random
> >>> contents when the test runs.
> >>>
> >>> When I add "vtkScatterPlotMatrix" as a Windows exception, the test
> >>> passes on this build.
> >>>
> >>> I always love running Debug Visual Studio builds for catching easy
> >>> errors like uninitialized variables and out of subscript references...
> >>>
> >>>
> >>> HTH,
> >>> D
> >>>
> >>>
> >>> On Wed, Apr 29, 2015 at 8:38 AM, David Cole <DLRdave at aol.com> wrote:
> >>> > I ran a build on my machine, named trivet, a Debug 64-bit build from
> >>> > VS 2013, and the test fails with a single assertion failure and 10-20
> >>> > mem leaks:
> >>> >
> >>> > https://open.cdash.org/testDetails.php?test=331705794&build=3791568
> >>> >
> >>> > Perhaps the "C:\Program Files (x86)\Microsoft Visual Studio
> >>> > 12.0\VC\INCLUDE\vector(1201) : Assertion failed: vector subscript out
> >>> > of range" report indicates the *real* cause of the problem on the Mac
> >>> > Release build. I'm not sure which class/method that comes from, but
> >>> > I'm about to run it and try to find out.
> >>> >
> >>> >
> >>> > David C.
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Apr 29, 2015 at 2:23 AM, Andrew Maclean
> >>> > <andrew.amaclean at gmail.com> wrote:
> >>> >> He Sean,
> >>> >>
> >>> >> I should clarify this a bit more.
> >>> >> vtkDataEncoder invokes a thread pool which doesn't clean up after
> use,
> >>> >> hence
> >>> >> the crashes after program execution, adding vtkDataEncoder to the
> list
> >>> >> of
> >>> >> excluded classes "almost" fixed this.
> >>> >> However Windows was still crashing when the program was run again,
> so,
> >>> >> adding vtkWebApplication (which is the only class that calls
> >>> >> vtkDataEncoder), to the list of excluded classes, fixed this issue.
> >>> >>
> >>> >> Notwithstanding this, it is puzzling, as I said in the previous
> e-mail
> >>> >> as to
> >>> >> why on Kamino we get a SIGSEGV at 0x0 address not mapped to object
> >>> >> since
> >>> >> vtkView is specifically excluded.
> >>> >>
> >>> >> Regards
> >>> >>    Andrew
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Wed, Apr 29, 2015 at 1:32 PM, Andrew Maclean
> >>> >> <andrew.amaclean at gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> Hi Sean,
> >>> >>>
> >>> >>> Yes, vtkDataEncoder and vtkWebApplication (which uses it) are
> >>> >>> excluded
> >>> >>> form TestSetGet.py and TestEmptyInput.py. This fixed the crashes
> and
> >>> >>> also
> >>> >>> the crash in windows when the program was run again. I think
> Windows
> >>> >>> was  a
> >>> >>> bit slow recovering memory. after program execution.
> >>> >>>
> >>> >>> What is puzzling is that TestGetSet excludes vtkView so
> >>> >>> vtkView.SetRepresentation() is never tested, this only fails on
> >>> >>> Kamino
> >>> >>> (release). It passes on trey (osX release) and also on megas.
> >>> >>>
> >>> >>> Regards
> >>> >>>    Andrew
> >>> >>>
> >>> >>>
> >>> >>> On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride
> >>> >>> <sean at rogue-research.com>
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> Did you fix the use-after-free we discussed on this list a few
> weeks
> >>> >>>> ago?
> >>> >>>>
> >>> >>>> Sean
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said:
> >>> >>>>
> >>> >>>> >David,
> >>> >>>> >   Thanks for your insights.
> >>> >>>> >Just finished testing this code on my Macbook Pro OS X Yosemite,
> >>> >>>> > Python
> >>> >>>> >2.7.6 after building VTK in both Debug and Release mode.
> Everything
> >>> >>>> > runs
> >>> >>>> > Ok
> >>> >>>> >so I don't think it is a typedef or macro related to a release
> >>> >>>> > build on
> >>> >>>> > OS
> >>> >>>> >X.
> >>> >>>> >
> >>> >>>> >Has anyone else got any suggestions?
> >>> >>>> >
> >>> >>>> >
> >>> >>>> >Regards
> >>> >>>> >   Andrew
> >>> >>>> >
> >>> >>>> >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi
> >>> >>>> > <david.gobbi at gmail.com>
> >>> >>>> > wrote:
> >>> >>>> >
> >>> >>>> >> Hi Andrew,
> >>> >>>> >>
> >>> >>>> >> The stack trace provides strong evidence that TestSetGet.py is
> >>> >>>> >> not
> >>> >>>> >> excluding vtkView on those dashboards, as ludicrous as that
> >>> >>>> >> sounds.
> >>> >>>> >>
> >>> >>>> >>     c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_
> >>> >>>> >>     PyvtkView_SetRepresentation(_object*, _object*)
> >>> >>>> >>
> >>> >>>> >> This method is only defined in vtkViewPython.cxx, and only
> >>> >>>> >> dir(vtk.vtkView) will return this method.  Calling dir() on the
> >>> >>>> >> vtkView
> >>> >>>> >> subclasses will not return this method.  Hence, the only reason
> >>> >>>> >> that
> >>> >>>> >> TestSetGet.py would be calling this method is if it was testing
> >>> >>>> >> vtkView.
> >>> >>>> >>
> >>> >>>> >> Perhaps someone added either a typedef or a macro that causes
> an
> >>> >>>> >> additional reference to vtkView to appear in the vtk module
> under
> >>> >>>> >> a
> >>> >>>> >> different name.
> >>> >>>> >>
> >>> >>>> >>  - David
> >>> >>>> >>
> >>> >>>> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean
> >>> >>>> >> <andrew.amaclean at gmail.com
> >>> >>>> >> > wrote:
> >>> >>>> >>
> >>> >>>> >>> Hi All,
> >>> >>>> >>>    I need some help here.
> >>> >>>> >>>
> >>> >>>> >>> I have converted TestSetGet.tcl to Python but I get a crash on
> >>> >>>> >>> the
> >>> >>>> >>> dashboard for kamino building osx in release mode, here:
> >>> >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789971
> >>> >>>> >>> and here:
> >>> >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789950
> >>> >>>> >>>
> >>> >>>> >>> In an earlier attempt, linux release on megas was also
> crashing
> >>> >>>> >>> in
> >>> >>>> >>> release mode:
> >>> >>>> >>>
> >>> >>>> >>>
> https://open.cdash.org/testDetails.php?test=331289192&build=3789418
> >>> >>>> >>> Based on this I excluded vtkScatterPlotMatrix which fixed it
> on
> >>> >>>> >>> megas
> >>> >>>> >>> but
> >>> >>>> >>> not on Kamino.
> >>> >>>> >>> So I excluded vtkChartMatrix and I still have the same errors
> on
> >>> >>>> >>> Kamino.
> >>> >>>> >>> But there are no clues as to where the crash is happening.
> >>> >>>> >>> However in
> >>> >>>> >>> looking at:
> >>> >>>> >>>
> >>> >>>> >>>
> https://open.cdash.org/testDetails.php?test=331378847&build=3789950
> >>> >>>> >>> I think it is in vtkView - which is already excluded.
> >>> >>>> >>> This could be the problem:
> >>> >>>> >>> void SetRepresentation (vtkDataRepresentation *rep)
> >>> >>>> >>> vtkDataRepresentation * GetRepresentation (int index=0)
> >>> >>>> >>>
> >>> >>>> >>> Can anyone help?
> >>> >>>> >>>
> >>> >>>> >>> I guess I can try excluding all the *View classes as
> documented
> >>> >>>> >>> in:
> >>> >>>> >>> http://www.vtk.org/doc/nightly/html/classvtkView.html
> >>> >>>> >>> Is there a less brute-force approach?
> >>> >>>> >>>
> >>> >>>> >>>
> >>> >>>> >>> The code is here:
> >>> >>>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151
> >>> >>>> >>>
> >>> >>>> >>> Thanks in advance for any help/guidance.
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> ___________________________________________
> >>> >>> Andrew J. P. Maclean
> >>> >>>
> >>> >>> ___________________________________________
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> ___________________________________________
> >>> >> Andrew J. P. Maclean
> >>> >>
> >>> >> ___________________________________________
> >>> >>
> >>> >> _______________________________________________
> >>> >> Powered by www.kitware.com
> >>> >>
> >>> >> Visit other Kitware open-source projects at
> >>> >> http://www.kitware.com/opensource/opensource.html
> >>> >>
> >>> >> Search the list archives at:
> >>> >> http://markmail.org/search/?q=vtk-developers
> >>> >>
> >>> >> Follow this link to subscribe/unsubscribe:
> >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers
> >>> >>
> >>> >>
> >>
> >>
> >>
> >>
> >> --
> >> ___________________________________________
> >> Andrew J. P. Maclean
> >>
> >> ___________________________________________
> >
> >
> >
> >
> > --
> > ___________________________________________
> > Andrew J. P. Maclean
> >
> > ___________________________________________
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at:
> http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150502/affd1d25/attachment-0001.html>


More information about the vtk-developers mailing list