MantisBT - VTK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012655VTK(No Category)public2011-10-14 10:552016-08-12 09:55
ReporterBen Payne 
Assigned ToDave DeMarle 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
ProjectKitware
Typecrash
Summary0012655: Data race in vtkAlgorithm triggered by vtkImageAppend
DescriptionI just spent several hours tracking down a mysterious crash, which appears to be due to an insidious race condition triggered when running a multi-threaded vtkImageAppend filter.

The crux of the problem is that vtkImageAppend::ThreadedRequestData() indirectly calls vtkAlgorithm::GetOutputPort() which, despite outward appearances is *not* thread-safe.

I found this race by running helgrind (a valgrind tool) on our application - which spits out the following (threads 8 and 9 are the algorithm's worker threads):

==4282== Possible data race during read of size 8 at 0x2c3f0c20 by thread 0000009
==4282== at 0xFBF50C: vtkSmartPointer<vtkAlgorithmOutput>::operator vtkAlgorithmOutput*() const (vtkSmartPointer.h:75)
==4282== by 0xFBE287: vtkAlgorithm::GetOutputPort(int) (vtkAlgorithm.cxx:1218)
==4282== by 0xFF4712: vtkExecutive::GetProducerPort(vtkDataObject*) (vtkExecutive.cxx:419)
==4282== by 0xFDD976: vtkDataObject::GetProducerPort() (vtkDataObject.cxx:362)
==4282== by 0x101C4DC: vtkImageData::GetScalarType() (vtkImageData.cxx:1498)
==4282== by 0x101C94F: vtkImageData::GetScalarSize() (vtkImageData.cxx:1579)
==4282== by 0xF42F2D: vtkImageAppend::InitOutput(int*, vtkImageData*) (vtkImageAppend.cxx:427)
==4282== by 0xF430CA: vtkImageAppend::ThreadedRequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*, vtkImageData***, vtkImageData**, int*, int) (vtkImageAppend.cxx:476)
==4282== by 0x10C2714: vtkThreadedImageAlgorithmThreadedExecute(void*) (vtkThreadedImageAlgorithm.cxx:202)
==4282== by 0x4C29D69: mythread_wrapper (hg_intercepts.c:221)
==4282== by 0x9C4CD8B: start_thread (pthread_create.c:304)
==4282== by 0xB74104C: clone (clone.S:112)
==4282== This conflicts with a previous write of size 8 by thread #8
==4282== at 0x1255D7A: vtkSmartPointerBase::Swap(vtkSmartPointerBase&) (vtkSmartPointerBase.cxx:105)
==4282== by 0x1255CF8: vtkSmartPointerBase::operator=(vtkSmartPointerBase const&) (vtkSmartPointerBase.cxx:88)
==4282== by 0xFBF162: vtkSmartPointer<vtkAlgorithmOutput>::operator=(vtkSmartPointer<vtkAlgorithmOutput> const&) (vtkSmartPointer.h:27)
==4282== by 0xFBE2C9: vtkAlgorithm::GetOutputPort(int) (vtkAlgorithm.cxx:1221)
==4282== by 0xFF4712: vtkExecutive::GetProducerPort(vtkDataObject*) (vtkExecutive.cxx:419)
==4282== by 0xFDD976: vtkDataObject::GetProducerPort() (vtkDataObject.cxx:362)
==4282== by 0x101C4DC: vtkImageData::GetScalarType() (vtkImageData.cxx:1498)
==4282== by 0x101C94F: vtkImageData::GetScalarSize() (vtkImageData.cxx:1579)
==4282== Address 0x2c3f0c20 is 0 bytes inside a block of size 8 alloc'd
==4282== at 0x4C28B82: operator new(unsigned long) (vg_replace_malloc.c:261)
==4282== by 0xFC0BB3: __gnu_cxx::new_allocator<vtkSmartPointer<vtkAlgorithmOutput> >::allocate(unsigned long, void const*) (new_allocator.h:89)
==4282== by 0xFC0948: std::_Vector_base<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > >::_M_allocate(unsigned long) (in /home/ben/Dev/virat2-superbuild-debug/TPL/VisGUI/bin/viqui)
==4282== by 0xFC02C3: std::vector<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > >::_M_fill_insert(__gnu_cxx::__normal_iterator<vtkSmartPointer<vtkAlgorithmOutput>*, std::vector<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > > >, unsigned long, vtkSmartPointer<vtkAlgorithmOutput> const&) (vector.tcc:414)
==4282== by 0xFBFBED: std::vector<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > >::insert(__gnu_cxx::__normal_iterator<vtkSmartPointer<vtkAlgorithmOutput>*, std::vector<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > > >, unsigned long, vtkSmartPointer<vtkAlgorithmOutput> const&) (stl_vector.h:859)
==4282== by 0xFBF4A4: std::vector<vtkSmartPointer<vtkAlgorithmOutput>, std::allocator<vtkSmartPointer<vtkAlgorithmOutput> > >::resize(unsigned long, vtkSmartPointer<vtkAlgorithmOutput>) (stl_vector.h:558)
==4282== by 0xFBC7D8: vtkAlgorithm::SetNumberOfOutputPorts(int) (vtkAlgorithm.cxx:772)
==4282== by 0x1014A64: vtkImageAlgorithm::vtkImageAlgorithm() (vtkImageAlgorithm.cxx:32)
==4282== by 0x10C1BE4: vtkThreadedImageAlgorithm::vtkThreadedImageAlgorithm() (vtkThreadedImageAlgorithm.cxx:31)
==4282== by 0xF420D9: vtkImageAppend::vtkImageAppend() (vtkImageAppend.cxx:31)
==4282== by 0xF42093: vtkImageAppend::New() (vtkImageAppend.cxx:28)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-10-14 10:55Ben PayneNew Issue
2012-11-04 16:53Leo LiuNote Added: 0029649
2012-11-05 13:03Ben PayneNote Added: 0029653
2012-11-05 13:50Leo LiuNote Added: 0029654
2013-06-24 21:25Dave DeMarleNote Added: 0031032
2013-07-22 12:37Dave DeMarleStatusbacklog => expired
2013-07-22 12:37Dave DeMarleAssigned To => Dave DeMarle
2016-08-12 09:55Kitware RobotNote Added: 0037250
2016-08-12 09:55Kitware RobotStatusexpired => closed
2016-08-12 09:55Kitware RobotResolutionopen => moved

Notes
(0029649)
Leo Liu   
2012-11-04 16:53   
Can you post your code?
(0029653)
Ben Payne   
2012-11-05 13:03   
Not our exact code, but here is a reduced test case that triggers the warning in helgrind:

#include <vtkImageAppend.h>
#include <vtkImageData.h>
#include <vtkNew.h>
#include <vtkPNGReader.h>

int main()
{
  vtkNew<vtkPNGReader> reader1;
  vtkNew<vtkPNGReader> reader2;
  vtkNew<vtkImageAppend> append;
  reader1->SetFileName("someimage.png");
  reader2->SetFileName("someimage.png");
  append->AddInputConnection(reader1->GetOutputPort());
  append->AddInputConnection(reader2->GetOutputPort());
  append->SetAppendAxis(2);
  append->Update();
  append->Print(std::cout);
}
(0029654)
Leo Liu   
2012-11-05 13:50   
This is most likely fixed by the vtk6 changes.

In the latest VTK, GetOutputPort() is no longer called from ThreadedRequestData()。 The call path reported by valgrind is no longer valid, since vtkDataObject::GetProducerPort() no longer exists.
(0031032)
Dave DeMarle   
2013-06-24 21:25   
Ben can you check if this is in fact fixed in VTK 6?
If not I will leave this open, otherwise I will close.

thanks
(0037250)
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.