Interesting possible bug with resizing an offscreen window

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Interesting possible bug with resizing an offscreen window

Prabhu Ramachandran-3

Hi all,

I am running into a very strange issue with resizing an offscreen window. It took me a few days to extract a simple VTK Python script to demonstrate this and the result is a rather strange script but shows that it is possible to put VTK into a race condition at best or in some cases completely mess up the rendering.  This happens on 8.1.1 or VTK master from yesterday.  I've tried this on Mac OS and also on Linux.  This does not happen when offscreen rendering is disabled.

The way I have setup the problem is rather unusual so I understand if this is not going to be fixed but I thought I might as well report it here in case it is of any use.

I've attached a simple Python script that only requires VTK-Python which demonstrates the problem, just run it and it will lock up VTK.  I was able to attach to the running process and see a backtrace that looks like below:


* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369
    frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244
    frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38
    frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 + 248
    frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers + 156
    frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken + 154
    frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence + 69
    frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248
    frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35
    frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63
    frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231
    frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263
    frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171
    frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435
    frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vtkRenderer::UpdateOpaquePolygonalGeometry() + 55
    frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() + 1956
    frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() + 181
    frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() + 1443
    frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() + 139
    frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vtkRenderWindow::DoStereoRender() + 140
    frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() + 596
    frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8.1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138
    frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497
    frame #25: 0x00000001008303d7 Python`call_function + 439
    frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346
    frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447
    frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100
    frame #29: 0x000000010078f26d Python`function_call + 381
    frame #30: 0x00000001007661f0 Python`PyObject_Call + 96
    frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + 1240
    frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045
    frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOpenGLResourceFreeCallback<vtkOpenGLPolyDataMapper>::Release() + 89
    frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58
    frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::DestroyWindow() + 95
    frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, int) + 598
    frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494


cheers,

Prabhu


_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers


offscreen_bug.py (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interesting possible bug with resizing an offscreen window

Allie Vacanti
Thanks for the report, I've made an issue here so this doesn't get lost in the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388

From the stack trace, it definitely  looks odd that destroying the window is triggering a render.

On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

I am running into a very strange issue with resizing an offscreen window. It took me a few days to extract a simple VTK Python script to demonstrate this and the result is a rather strange script but shows that it is possible to put VTK into a race condition at best or in some cases completely mess up the rendering.  This happens on 8.1.1 or VTK master from yesterday.  I've tried this on Mac OS and also on Linux.  This does not happen when offscreen rendering is disabled.

The way I have setup the problem is rather unusual so I understand if this is not going to be fixed but I thought I might as well report it here in case it is of any use.

I've attached a simple Python script that only requires VTK-Python which demonstrates the problem, just run it and it will lock up VTK.  I was able to attach to the running process and see a backtrace that looks like below:


* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369
    frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244
    frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38
    frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 + 248
    frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers + 156
    frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken + 154
    frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence + 69
    frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248
    frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35
    frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63
    frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231
    frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263
    frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171
    frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435
    frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vtkRenderer::UpdateOpaquePolygonalGeometry() + 55
    frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() + 1956
    frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() + 181
    frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() + 1443
    frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() + 139
    frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vtkRenderWindow::DoStereoRender() + 140
    frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() + 596
    frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8.1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138
    frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497
    frame #25: 0x00000001008303d7 Python`call_function + 439
    frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346
    frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447
    frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100
    frame #29: 0x000000010078f26d Python`function_call + 381
    frame #30: 0x00000001007661f0 Python`PyObject_Call + 96
    frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + 1240
    frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045
    frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOpenGLResourceFreeCallback<vtkOpenGLPolyDataMapper>::Release() + 89
    frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58
    frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::DestroyWindow() + 95
    frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, int) + 598
    frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494


cheers,

Prabhu


_______________________________________________
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:
https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Interesting possible bug with resizing an offscreen window

Ken Martin
The python script adds a Render() call in a callback that gets called whenever the Mapper is modified(). During the resource freeing pass the mapper gets modified so the callback invokes a render that happens in the middle of DestroyWindow.

The crash is bad, but... as Prabhu mentions we sort of get why it happens. Ideally the app would remove the observers prior to destroying the window. Another approach I have seen is to have a flag indicating IsDestructing and if a Render/etc happens when IsDestructing is true ignore it. etc.


On Mon, Sep 10, 2018 at 10:37 AM, Allie Vacanti <[hidden email]> wrote:
Thanks for the report, I've made an issue here so this doesn't get lost in the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388

From the stack trace, it definitely  looks odd that destroying the window is triggering a render.

On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

I am running into a very strange issue with resizing an offscreen window. It took me a few days to extract a simple VTK Python script to demonstrate this and the result is a rather strange script but shows that it is possible to put VTK into a race condition at best or in some cases completely mess up the rendering.  This happens on 8.1.1 or VTK master from yesterday.  I've tried this on Mac OS and also on Linux.  This does not happen when offscreen rendering is disabled.

The way I have setup the problem is rather unusual so I understand if this is not going to be fixed but I thought I might as well report it here in case it is of any use.

I've attached a simple Python script that only requires VTK-Python which demonstrates the problem, just run it and it will lock up VTK.  I was able to attach to the running process and see a backtrace that looks like below:


* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369
    frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244
    frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38
    frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 + 248
    frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers + 156
    frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken + 154
    frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence + 69
    frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248
    frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35
    frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63
    frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231
    frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263
    frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171
    frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435
    frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vtkRenderer::UpdateOpaquePolygonalGeometry() + 55
    frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() + 1956
    frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() + 181
    frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() + 1443
    frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() + 139
    frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vtkRenderWindow::DoStereoRender() + 140
    frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() + 596
    frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8.1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138
    frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497
    frame #25: 0x00000001008303d7 Python`call_function + 439
    frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346
    frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447
    frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100
    frame #29: 0x000000010078f26d Python`function_call + 381
    frame #30: 0x00000001007661f0 Python`PyObject_Call + 96
    frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + 1240
    frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045
    frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOpenGLResourceFreeCallback<vtkOpenGLPolyDataMapper>::Release() + 89
    frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58
    frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::DestroyWindow() + 95
    frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, int) + 598
    frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494


cheers,

Prabhu


_______________________________________________
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:
https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers





--
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Interesting possible bug with resizing an offscreen window

Ken Martin
In reply to this post by Allie Vacanti
The issue here I think is why destroy the window on a resize (for offscreen). We have the same code on another platform and I do not think it is needed anymore. Resizing offscreen rendering should just be changing the fbo size. That is probably what we need to fix. Then the problem goes away.

On Mon, Sep 10, 2018 at 10:37 AM, Allie Vacanti <[hidden email]> wrote:
Thanks for the report, I've made an issue here so this doesn't get lost in the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388

From the stack trace, it definitely  looks odd that destroying the window is triggering a render.

On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

I am running into a very strange issue with resizing an offscreen window. It took me a few days to extract a simple VTK Python script to demonstrate this and the result is a rather strange script but shows that it is possible to put VTK into a race condition at best or in some cases completely mess up the rendering.  This happens on 8.1.1 or VTK master from yesterday.  I've tried this on Mac OS and also on Linux.  This does not happen when offscreen rendering is disabled.

The way I have setup the problem is rather unusual so I understand if this is not going to be fixed but I thought I might as well report it here in case it is of any use.

I've attached a simple Python script that only requires VTK-Python which demonstrates the problem, just run it and it will lock up VTK.  I was able to attach to the running process and see a backtrace that looks like below:


* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369
    frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244
    frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38
    frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 + 248
    frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers + 156
    frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken + 154
    frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence + 69
    frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248
    frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35
    frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63
    frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231
    frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263
    frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171
    frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435
    frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vtkRenderer::UpdateOpaquePolygonalGeometry() + 55
    frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() + 1956
    frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() + 181
    frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() + 1443
    frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() + 139
    frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vtkRenderWindow::DoStereoRender() + 140
    frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() + 596
    frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8.1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138
    frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497
    frame #25: 0x00000001008303d7 Python`call_function + 439
    frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346
    frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447
    frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100
    frame #29: 0x000000010078f26d Python`function_call + 381
    frame #30: 0x00000001007661f0 Python`PyObject_Call + 96
    frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + 1240
    frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045
    frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOpenGLResourceFreeCallback<vtkOpenGLPolyDataMapper>::Release() + 89
    frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58
    frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::DestroyWindow() + 95
    frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, int) + 598
    frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494


cheers,

Prabhu


_______________________________________________
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:
https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers





--
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers