[vtk-developers] Need help with a crash on Kamino OSX Release mode.
Gru
gururagaven at yahoo.co.in
Fri May 1 09:23:16 EDT 2015
I want to unsunscribe this vtk
Any one can suggest me
Sent from my Sony Xperia™ smartphone
---- Utkarsh Ayachit 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
>>
>>
>_______________________________________________
>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/20150501/6e2ac9b5/attachment-0001.html>
More information about the vtk-developers
mailing list