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