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

Andrew Maclean andrew.amaclean at gmail.com
Fri May 1 01:20:31 EDT 2015


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

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


More information about the vtk-developers mailing list