MantisBT - VTK
View Issue Details
0008582VTK(No Category)public2009-02-23 07:492016-08-12 09:55
Joó Péter 
Kitware Robot 
normalminorrandom
closedmoved 
LinuxRed Hat4.0.2
 
 
0008582: CRASH: Invoking VolumeMapperComputeGradientsStartEvent and VolumeMapperComputeGradientsEndEvent evens are not thread safe
At file: vtkFixedPointVolumeRayCastMapper.cxx
at method: void vtkFixedPointVolumeRayCastMapperComputeCS1CGradients(...)

This method deliberately calls the
 me->InvokeEvent( vtkCommand::VolumeMapperComputeGradientsStartEvent, NULL );
 me->InvokeEvent( vtkCommand::VolumeMapperComputeGradientsEndEvent, NULL );
methods to inform the application layer that the events
 VolumeMapperComputeGradientsStartEvent
 VolumeMapperComputeGradientsEndEvent
are about to happen.

However the vtkFixedPointVolumeRayCastMapperComputeCS1CGradients method is designed to be run on multiple threads/processor but it uses the vtkSubjectHelper::InvokeEvent method which is not thread safe.

In our case VTK created 3 threads for gradient computation.
During the computation and during the above InvokeEvent calls the vtkObjectBase::ReferenceCount member was compromised inside the our subclassed vtkCommand instance.
This means that the reference count decreased to 0 and the vtkCommand deleted while there were still references for it.
After a while the framework dereferenced that deleted class --> it lead to crash

Solution:
=========
VTK 5.2.0 as been patched in order to avoid the InvokeEvent from multiple threads. The patch consist of calling the InvokeEvent methods right before thread creation (vtkCommand::VolumeMapperComputeGradientsStartEvent) and right after the thread exit (vtkCommand::VolumeMapperComputeGradientsEndEvent)
These takes place at file
  vtkFixedPointVolumeRayCastMapper.cxx
at method
  vtkFixedPointVolumeRayCastMapper::ComputeGradients

Note:
=====
The other call for
  me->InvokeEvent( vtkCommand::VolumeMapperComputeGradientsProgressEvent, args );
has succeeded without such a problem because it was fired in case of:
  thread_id == 0
which was on purpose, I presume.
reading the code is enough to prove that such a scenario exists in VTK 5.2.0
It was happened on a
- HP xw8400 Workstation (4x3.0GHz Xeon CPU, 4GB RAM, 2x150MB image disk)
- Linux version 2.6.15-2.5 (root@alfred) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP PREEMPT Tue Sep 19 10:56:25 CDT 2006
No tags attached.
cxx original-vtkFixedPointVolumeRayCastMapper.cxx (120,079) 2009-02-23 07:58
https://www.vtk.org/Bug/file/7072/original-vtkFixedPointVolumeRayCastMapper.cxx
cxx patched-vtkFixedPointVolumeRayCastMapper.cxx (123,007) 2009-02-23 07:58
https://www.vtk.org/Bug/file/7073/patched-vtkFixedPointVolumeRayCastMapper.cxx
Issue History
2009-02-23 07:49Joó PéterNew Issue
2009-02-23 07:58Joó PéterNote Added: 0015288
2009-02-23 07:58Joó PéterFile Added: original-vtkFixedPointVolumeRayCastMapper.cxx
2009-02-23 07:58Joó PéterFile Added: patched-vtkFixedPointVolumeRayCastMapper.cxx
2009-02-23 07:59Joó PéterNote Edited: 0015288
2011-06-16 13:11Zack GalbreathCategory => (No Category)
2016-08-12 09:55Kitware RobotNote Added: 0037056
2016-08-12 09:55Kitware RobotStatusexpired => closed
2016-08-12 09:55Kitware RobotResolutionopen => moved
2016-08-12 09:55Kitware RobotAssigned To => Kitware Robot

Notes
(0015288)
Joó Péter   
2009-02-23 07:58   
(edited on: 2009-02-23 07:59)
I have been attached the original VTK 5.2.0 file as
"original-vtkFixedPointVolumeRayCastMapper.cxx"
and our patch based on the above as
"patched-vtkFixedPointVolumeRayCastMapper.cxx"

Please review/integrate/test this fix into future versions of VTK!

(0037056)
Kitware Robot   
2016-08-12 09:55   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page.