View Issue Details [ Jump to Notes ] [ Print ]
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 
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)
TagsNo tags attached.
ProjectKitware
Typecrash
Attached Files

 Relationships

  Notes
(0029649)
Leo Liu (developer)
2012-11-04 16:53

 Can you post your code?
(0029653)
Ben Payne (reporter)
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 (developer)
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 (administrator)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2011-10-14 10:55 Ben Payne New Issue
2012-11-04 16:53 Leo Liu Note Added: 0029649
2012-11-05 13:03 Ben Payne Note Added: 0029653
2012-11-05 13:50 Leo Liu Note Added: 0029654
2013-06-24 21:25 Dave DeMarle Note Added: 0031032
2013-07-22 12:37 Dave DeMarle Status backlog => expired
2013-07-22 12:37 Dave DeMarle Assigned To => Dave DeMarle
2016-08-12 09:55 Kitware Robot Note Added: 0037250
2016-08-12 09:55 Kitware Robot Status expired => closed
2016-08-12 09:55 Kitware Robot Resolution open => moved

Copyright © 2000 - 2018 MantisBT Team