MantisBT - VTK
View Issue Details
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 
ProjectTBD
Typeincorrect functionality
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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0015365closed Cory Quammen Crash in vtkLookupTableMapData if called from multiple threads 
Attached Files? vtk.bug.rpt (18,217) 2015-12-23 06:24
https://www.vtk.org/Bug/file/9986/vtk.bug.rpt
Issue History
Date ModifiedUsernameFieldChange
2015-12-23 06:24Andrei TerechkoNew Issue
2015-12-23 06:24Andrei TerechkoFile Added: vtk.bug.rpt
2016-01-14 13:10David GobbiRelationship addedrelated to 0015365
2016-01-14 13:17David GobbiNote Added: 0035652
2016-01-15 10:48Cory QuammenNote Added: 0035656
2016-01-15 22:55Cory QuammenNote Added: 0035658
2016-01-15 22:57Cory QuammenAssigned To => Cory Quammen
2016-01-15 22:57Cory QuammenStatusbacklog => gerrit review
2016-05-13 17:03Cory QuammenNote Added: 0035952
2016-05-13 17:03Cory QuammenStatusgerrit review => closed
2016-05-13 17:03Cory QuammenResolutionopen => fixed
2016-05-13 17:03Cory QuammenFixed in Version => 7.1.0

Notes
(0035652)
David Gobbi   
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   
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   
2016-01-15 22:55   
Patch posted:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1092 [^]
(0035952)
Cory Quammen   
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.