 |
I suspect that what's happened here is that the forceRender timeout is happening while the image are still being updated - on windows it seems there are several refreshes going on while the data is being loaded, and if the event loop has a chance to fire the timer while the vtk pipeline is in an inconsistent state it can lead to this crash. |
|
|
I did some more experimentation and found that I could click apply repeatedly for 20 or 30 times but eventually I got the crash with the same stack trace as reported above. |
 |
I can't think of why there could be a refresh while the output of a CLI is being updated. Both are supposed to happen in the same thread. |
|
|
I'm not sure either, but there it is :) What I guess happens is that something is triggering processEvents or returning control to the event loop as a byproduct of the load process. I guess I'll try on mac also to see if I get the same behavior. <testing...> There is definitely something funny going on, because if you follow the directions on how to reproduce the issue and you repeatedly click the Apply button you can see the sliders in the slice controllers jump around, but they have no reason to do that because they should "know the right answer" before they are ever rendered. I also notice that on mac I get the following error message, which must also relate to rendering when the pipeline isn't set up yet: ERROR: In /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDemandDrivenPipeline.cxx, line 727 |
|
|
The crash reported by Steve is in the main thread. Here is what happens in Thread 4 at the time of the crash: |
|
|
Reminder sent to: millerjv Jim - Can you have a look at this and help us think through it? On the hangout yesterday we realized that the MRMLImageIDIO is running in the task thread, but it ends up calling SetAndObserveImageData and the can modify the pipeline during a render depending on the timing. We could replicate this on windows and mac, on both debug and release builds by following the instructions in this bug report (click the Apply button repeatedly as fast as possible and it eventually happens). -Steve |
|
|
In theory this should also have happened in slicer3, but I could not replicate it with several attempts on a mac release build. |
|
|
The problem is that the volume node now sends an ImageDataModified event in addition to a normal Modfied event: https://github.com/Slicer/Slicer/blob/master/Libs/MRML/Core/vtkMRMLVolumeNode.cxx#L657 The MRMLIDImageIO (running in the thread) sets the image data for a node after disabling modified events, but this doesn't disable the new ImageDataModfied event: https://github.com/Slicer/Slicer/blob/master/Libs/MRML/IDImageIO/itkMRMLIDImageIO.cxx#L587 |
|
|
Can you please review my suggested fix: |
 |
Just scanned this briefly. I probably would have disabled the ImageDataModified event instead. But I like the idea of catching all events in the thread and then scheduling them in the main thread. Is this implementation general? Meaning any event can be caught and rescheduled in the main thread? |
|
|
Yes, it's (somewhat) generic: it catches (and reschedules) all the events fired by the "output" nodes. |
|
|
Fixed in r22196 |
 |
Closing resolved issues that have not been updated in more than 3 months |
- Anonymous
