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

Wed Apr 29 08:57:54 EDT 2015

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
>>
>>