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

Andrew Maclean andrew.amaclean at gmail.com
Sun May 3 21:35:27 EDT 2015 

Hi Utkarsh,
   Your fixes have worked perfectly. Thankyou for taking the time to look
at Kamino for me. I owe you a beer!

Seriously I would have never found the problems as all the resting on my
machines was consistently clean. This is the strength of Kitware in that
the testing environment is broad based and people are prepared to give up
some time to look into issues and suggest fixes.

TestSetGet.py is now ready for review along with the changes
to vtkOverlappingAMR, vtkStructuredAMRGridConnectivity,
vtkPStructuredGridConnectivity, vtkView.

Regards
    Andrew



On Sun, May 3, 2015 at 1:04 AM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com
> wrote:

> Andrew,
>
> Attached is a patch that fixes issues with
> 'vtk-kamino-osx-shared-release+mpi+python+tbb' builder.
>
> Utkarsh
>
>
> On Fri, May 1, 2015 at 4:02 PM, Andrew Maclean
> <andrew.amaclean at gmail.com> wrote:
> > 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
> >> >
> >> >
>



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150504/817b275f/attachment-0001.html>

More information about the vtk-developers mailing list