View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015903VTK(No Category)public2015-12-23 06:242016-05-13 17:03
ReporterAndrei Terechko 
Assigned ToCory Quammen 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version6.3.0 
Target VersionFixed in Version7.1.0 
Summary0015903: Race condition in accessing lookup table bwLut from vtkLookupTableMapData() in the TestMedical3 example
DescriptionENVIRONMENT
Ubuntu 14.04, x86_64

VERSION
VTK’s branch master, commit a846baedc8d52120ab308ec4dd8c86c7831fff78

STEPS TO REPRODUCE:
$ git clone https://gitlab.kitware.com/vtk/vtk.git [^]
$ mkdir build
$ cd build
$ cmake -DBUILD_EXAMPLES=on ../vtk
$ ./bin/MedicalExamplesCxxTests TestMedical3 ExternalData/Testing/Data/headsq/quarter -D ExternalData/Testing -T Testing/Temporary -V ExternalData/Examples/Medical/Cxx/Baseline/TestMedical3.png

OBSERVED BEHAVIOR:
The test succeeds. However, the software verification tool Pareon Verify (http://pareonverify.com/ [^]) reports concurrent reads and writes to the bwLut lookup table from vtkLookupTableMapData() executed in different threads. The detailed error report from Pareon Verify is attached in vtk.bug.rpt. Such concurrent accesses without synchronization constitute a critical race condition that can lead to program crashes and malfunctioning.

EXPECTED BEHAVIOR:
Accesses to the bwLut data structure from concurrent threads should be either protected with synchronization or the data structure needs to be duplicated and the algorithm adjusted accordingly.

Since the example is intended to illustrate proper and safe use of VTK, the described above race condition can mislead the end users of the software.
TagsNo tags attached.
ProjectTBD
Typeincorrect functionality
Attached Files? file icon vtk.bug.rpt [^] (18,217 bytes) 2015-12-23 06:24

 Relationships
related to 0015365closedCory Quammen Crash in vtkLookupTableMapData if called from multiple threads 

  Notes
(0035652)
David Gobbi (developer)
2016-01-14 13:17

 This race condition seems to the one reported in issue 0015365, which was marked as resolved prior to VTK 6.3. The code will have to be re-examined if the race condition is still present.
(0035656)
Cory Quammen (developer)
2016-01-15 10:48

 Thanks for supplying the bug report. Pareon Verify looks like a very nice tool.

I can see where the concurrent reads and writes are happening. The writes are to the special out-of-range and NaN colors at the end of the table. The good news is that each thread will write these values in vtkLookupTableMapData() prior to reading from them, and they will all write the same color values taken from the member variables in the same vtkLookupTable, so the race condition shouldn't lead to incorrect results.

It would be better to write these values to the tables in a single thread when building the table prior to mapping scalars... I'll see if there is a place that makes sense where this should be done.
(0035658)
Cory Quammen (developer)
2016-01-15 22:55

 Patch posted:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1092 [^]
(0035952)
Cory Quammen (developer)
2016-05-13 17:03

 Fixed in commit

commit e3a8a1ec32c96fe65c0542bab0ff906de03f362b
Author: Cory Quammen <cory.quammen@kitware.com>
Date: Fri Jan 15 14:54:34 2016 -0500

    BUG 15903: Fix race condition in setting special colors in table
    
    In vtkLookupTableMapData(), the special colors were set in the lookup
    table prior to doing the mapping. This can lead to a race condition if
    multiple threads call this function at the same time. Normally, this
    shouldn't be a problem, because if the vtkLookupTable used to fill in
    the table values is the same, each thread will write the same values
    to each entry in the table. Some verification tools, however, will
    note that more than one thread is writing to the same memory location
    at a time.
    
    Avoid this by setting the special colors when the lookup table is built
    or when custom table values are set.

 Issue History
Date Modified Username Field Change
2015-12-23 06:24 Andrei Terechko New Issue
2015-12-23 06:24 Andrei Terechko File Added: vtk.bug.rpt
2016-01-14 13:10 David Gobbi Relationship added related to 0015365
2016-01-14 13:17 David Gobbi Note Added: 0035652
2016-01-15 10:48 Cory Quammen Note Added: 0035656
2016-01-15 22:55 Cory Quammen Note Added: 0035658
2016-01-15 22:57 Cory Quammen Assigned To => Cory Quammen
2016-01-15 22:57 Cory Quammen Status backlog => gerrit review
2016-05-13 17:03 Cory Quammen Note Added: 0035952
2016-05-13 17:03 Cory Quammen Status gerrit review => closed
2016-05-13 17:03 Cory Quammen Resolution open => fixed
2016-05-13 17:03 Cory Quammen Fixed in Version => 7.1.0

Copyright © 2000 - 2018 MantisBT Team