MantisBT - VTK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012229VTK(No Category)public2011-05-27 07:192011-06-30 07:59
ReporterDominik Szczerba 
Assigned ToDavid Gobbi 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSUbuntu 10.04 64 bitOS Version10.04
Product Version 
Target VersionFixed in Version 
ProjectTBD
Typeincorrect functionality
Summary0012229: vtkImageAppend does not work correctly with multiple threads
DescriptionvtkImageAppend only works correctly with one thread. With more
it crashes reporting incorrect input/output pointers.
Steps To Reproduceappend = vtkImageAppend()
append.SetPreserveExtents(1)
# append.SetNumberOfThreads(1) # uncomment to prevent the crash

for i in range(NINPUTS):
    filename = args[i]
    reader = vtkXMLImageDataReader()
    reader.SetFileName(filename)
    reader.Update()
    dataset = vtkImageData()
    dataset.DeepCopy(reader.GetOutput())
    append.AddInput(dataset)
append.Update()

Result:

ERROR: In /home/domel/pack/vtk-5.6.1/Filtering/vtkImageData.cxx, line 2094
vtkImageData (0x2c246a0): GetPointer: Pixel (0, 0, 269) not in current extent: (0, 575, 0, 447, 101, 220)

ERROR: In /home/domel/pack/vtk-5.6.1/Filtering/vtkImageData.cxx, line 2094
vtkImageData (0x2c246a0): GetPointer: Pixel (0, 0, 245) not in current extent: (0, 575, 0, 447, 101, 220)

ERROR: In /home/domel/pack/vtk-5.6.1/Filtering/vtkImageData.cxx, line 2094
vtkImageData (0x2c246a0): GetPointer: Pixel (0, 0, 221) not in current extent: (0, 575, 0, 447, 101, 220)

Segmentation fault
Additional InformationSee the vtk mailing list thread "vtkImageAppend does not work correctly with multiple threads"
TagsNo tags attached.
Relationships
Attached Filesbz2 data.tar.bz2 (125,146) 2011-05-27 07:19
https://www.vtk.org/Bug/file/8901/data.tar.bz2
Issue History
Date ModifiedUsernameFieldChange
2011-05-27 07:19Dominik SzczerbaNew Issue
2011-05-27 07:19Dominik SzczerbaFile Added: data.tar.bz2
2011-05-27 09:34David GobbiAssigned To => David Gobbi
2011-05-27 09:34David GobbiStatusbacklog => tabled
2011-05-27 09:36David GobbiNote Added: 0026633
2011-05-27 09:36David GobbiStatustabled => @40@
2011-05-27 12:04Dominik SzczerbaNote Added: 0026634
2011-05-27 12:13David GobbiNote Added: 0026635
2011-05-28 12:01Dominik SzczerbaNote Added: 0026645
2011-05-28 13:08David GobbiNote Added: 0026646
2011-06-10 16:05Dominik SzczerbaNote Added: 0026826
2011-06-10 16:25David GobbiNote Added: 0026827
2011-06-11 06:11Dominik SzczerbaNote Added: 0026832
2011-06-11 12:47David GobbiNote Added: 0026835
2011-06-11 17:08Dominik SzczerbaNote Added: 0026839
2011-06-11 17:21Dominik SzczerbaNote Added: 0026840
2011-06-11 18:01David GobbiNote Added: 0026841
2011-06-14 16:05Dominik SzczerbaNote Added: 0026866
2011-06-30 07:57David GobbiProject => TBD
2011-06-30 07:57David GobbiType => incorrect functionality
2011-06-30 07:57David GobbiNote Added: 0026916
2011-06-30 07:57David GobbiStatusbacklog => tabled
2011-06-30 07:57David GobbiResolutionopen => fixed
2011-06-30 07:59David GobbiStatustabled => closed

Notes
(0026633)
David Gobbi   
2011-05-27 09:36   
Confirmed, when I set the number of threads to 8 the program crashed (with two and four threads it did not crash). On my machine, the following patch stopped the crash:

diff --git a/Imaging/vtkImageAppend.cxx b/Imaging/vtkImageAppend.cxx
index 975fe63..fb2fab7 100644
--- a/Imaging/vtkImageAppend.cxx
+++ b/Imaging/vtkImageAppend.cxx
@@ -267,7 +267,7 @@ int vtkImageAppend::RequestUpdateExtent(
 }
 
 //----------------------------------------------------------------------------
-void vtkImageAppendGetContinuosIncrements
+void vtkImageAppendGetContinuousIncrements
   (int wExtent[6], int sExtent[6], vtkIdType nComp, bool forCells,
    vtkIdType &incX,
    vtkIdType &incY,
@@ -346,12 +346,12 @@ void vtkImageAppendExecute(vtkImageAppend *self, int id,
   unsigned long target;
   double dnArrays = (double)nArrays;
 
- vtkImageAppendGetContinuosIncrements(inData->GetExtent(), inExt, numComp, fo
- inIncX, inIncY, inIncZ);
+ vtkImageAppendGetContinuousIncrements(
+ inData->GetExtent(), inExt, numComp, forCells, inIncX, inIncY, inIncZ);
 
   //cerr << "IN INCS " << inIncX << " " << inIncY << " " << inIncZ << endl;
- vtkImageAppendGetContinuosIncrements(outData->GetExtent(), outExt, numComp,
- outIncX, outIncY, outIncZ);
+ vtkImageAppendGetContinuousIncrements(
+ outData->GetExtent(), outExt, numComp, forCells, outIncX, outIncY, outIncZ
   //cerr << "OUT INCS " << outIncX << " " << outIncY << " " << outIncZ << endl
 
   int ptAdjust = (forCells?0:1);
@@ -508,7 +508,9 @@ void vtkImageAppend::ThreadedRequestData (
       c_out[2] = cOutExt[4];
 
       // do a quick check to see if the input is used at all.
- if (inExt[this->AppendAxis*2] <= inExt[this->AppendAxis*2 + 1])
+ if (inExt[0] <= inExt[1] &&
+ inExt[2] <= inExt[3] &&
+ inExt[4] <= inExt[5])
         {
         vtkIdType ai;
         vtkDataArray *inArray;
(0026634)
Dominik Szczerba   
2011-05-27 12:04   
Did you make sure that this fix will not break PreserveExtents = off and appending along the AppendAxis?
(0026635)
David Gobbi   
2011-05-27 12:13   
I only tested the nightly regression tests and the one test that you provided. My patch should not have any impact on PreserveExtents On/Off but please let me know if you have any further issues.
(0026645)
Dominik Szczerba   
2011-05-28 12:01   
I am seldom getting some unreproducible crashes with some combinations of my datasets. I am as of yet unable to isolate a test case. Meanwhile, again, my datasets are overlapping and I PreserveExtents, would that potentially result in any race conditions for parallel memory updates?
(0026646)
David Gobbi   
2011-05-28 13:08   
There isn't anything that I can see in the code that would cause a race condition, so I cannot really help you with that. Unpredictable crashes can also be caused by uninitialized memory reads. Can you run your code inside valgrind?
(0026826)
Dominik Szczerba   
2011-06-10 16:05   
I have a reproducible crash, problem is it involves large datasets. Where can I send big example data?
(0026827)
David Gobbi   
2011-06-10 16:25   
I don't have any specific place for receiving large data. Can you send a gdb stack trace?
(0026832)
Dominik Szczerba   
2011-06-11 06:11   
Here the requested backtrace (run with 8 threads)

ERROR: In /home/domel/pack/vtk-5.6.1/Filtering/vtkImageData.cxx, line 2110
vtkImageData (0xcb7150): Coordinate (-1, -3, -770) out side of array (max = -2137486337

#0 memset () at ../sysdeps/x86_64/memset.S:1016
#1 0x00007fffef00d4bd in vtkImageAppend::InitOutput (this=<value optimized out>, outExt=<value optimized out>,
    outData=<value optimized out>) at /usr/include/bits/string3.h:86
#2 0x00007fffef00d534 in vtkImageAppend::ThreadedRequestData (this=0x0, inputVector=<value optimized out>, inData=0x359,
    outData=0x300000, outExt=0x7fffe00e8e50, id=1) at /home/domel/pack/vtk-5.6.1/Imaging/vtkImageAppend.cxx:476
#3 0x00007fffeecaabfa in vtkThreadedImageAlgorithmThreadedExecute (arg=<value optimized out>)
    at /home/domel/pack/vtk-5.6.1/Filtering/vtkThreadedImageAlgorithm.cxx:202
#4 0x00007ffff7bc6971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#5 0x00007ffff6aa292d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6 0x0000000000000000 in ?? ()
(0026835)
David Gobbi   
2011-06-11 12:47   
The imagedata error says the MaxId of the output image array is "max = -2137486337", so the array has definitely been corrupted somehow, sometime before the error was actually thrown.

The best way to debug memory corruption errors is with valgrind,

valgrind --db-attach=yes <your executable with arguments>

It will stop when the first bad memory access occurs and will allow you to enter gdb at that point.
(0026839)
Dominik Szczerba   
2011-06-11 17:08   
Below the requested output:

> valgrind --db-attach=yes python script.py

[loooong list of errrors coming from python like invalid reads etc.]


0 boy3_shank_05_08_09.xmf
==6866== Warning: set address range perms: large range [0x1d37204c, 0x324da490) (undefined)
==6866== Warning: set address range perms: large range [0x1d372040, 0x324da490) (defined)
==6866== Warning: set address range perms: large range [0x3927e040, 0x4e3e6490) (undefined)
==6866== Warning: set address range perms: large range [0x1d372030, 0x324da4a0) (noaccess)
==6866== Warning: set address range perms: large range [0x1d372040, 0x324da490) (undefined)
(-0.11590000241994858, -0.045484200119972229, 1210.8699951171875)
(0.50800001621246338, 0.50800001621246338, 0.50800001621246338)
(0, 983, 0, 764, 0, 469)
Reference origin: (-0.11590000241994858, -0.045484200119972229, 1210.8699951171875)
1 boy3_shoulder_05_08_09.xmf
==6866== Warning: set address range perms: large range [0x3927e030, 0x4e3e64a0) (noaccess)
==6866== Warning: set address range perms: large range [0x3927e04c, 0x4e3e6490) (undefined)
==6866== Warning: set address range perms: large range [0x3927e040, 0x4e3e6490) (defined)
==6866== Warning: set address range perms: large range [0x4e3e7040, 0x6354f490) (undefined)
==6866== Warning: set address range perms: large range [0x3927e030, 0x4e3e64a0) (noaccess)
==6866== Warning: set address range perms: large range [0x3927e040, 0x4e3e6490) (undefined)
(0.88410001993179321, -1.0454800128936768, -0.12600000202655792)
(0.50800001621246338, 0.50800001621246338, 0.50800001621246338)
(0, 983, 0, 764, 0, 469)
new origin: (-0.11590000241994858, -0.045484200119972229, 1210.8699951171875)
dext: [1, -1, -2383]
new extent: [1, 984, -1, 763, -2383, -1914]
updating...
==6866== Warning: set address range perms: large range [0x63550040, 0x786b8490) (undefined)
ERROR: In /home/domel/pack/vtk-5.6.1/Filtering/vtkImageData.cxx, line 2110
vtkImageData (0x6b59d90): Coordinate (0, -1, -2383) out side of array (max = -2142350267

==6866== Invalid write of size 1
==6866== at 0x4C2A396: memset (mc_replace_strmem.c:602)
==6866== by 0xDFE24BC: vtkImageAppend::InitOutput(int*, vtkImageData*) (string3.h:86)
==6866== by 0xDFE2533: vtkImageAppend::ThreadedRequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*, vtkImageData***, vtkImageData**, int*, int) (vtkImageAppend.cxx:476)
==6866== by 0xE700BF9: vtkThreadedImageAlgorithmThreadedExecute(void*) (vtkThreadedImageAlgorithm.cxx:202)
==6866== by 0xEB3DCEA: vtkMultiThreader::SingleMethodExecute() (vtkMultiThreader.cxx:394)
==6866== by 0xE700945: vtkThreadedImageAlgorithm::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) (vtkThreadedImageAlgorithm.cxx:291)
==6866== by 0xE5EBC73: vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) (vtkExecutive.cxx:747)
==6866== by 0xE5DF7DB: vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) (vtkDemandDrivenPipeline.cxx:507)
==6866== by 0xE5E289A: vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) (vtkDemandDrivenPipeline.cxx:279)
==6866== by 0xE6F15F0: vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) (vtkStreamingDemandDrivenPipeline.cxx:202)
==6866== by 0xE5E25DE: vtkDemandDrivenPipeline::UpdateData(int) (vtkDemandDrivenPipeline.cxx:449)
==6866== by 0xE6F080A: vtkStreamingDemandDrivenPipeline::Update(int) (vtkStreamingDemandDrivenPipeline.cxx:246)
==6866== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6866==
==6866==
==6866== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----
(0026840)
Dominik Szczerba   
2011-06-11 17:21   
And after detaching from the debugger:


==6866== HEAP SUMMARY:
==6866== in use at exit: 1,421,939,923 bytes in 11,471 blocks
==6866== total heap usage: 31,521 allocs, 20,050 frees, 2,489,122,324 bytes allocated
==6866==
==6866== LEAK SUMMARY:
==6866== definitely lost: 144 bytes in 12 blocks
==6866== indirectly lost: 0 bytes in 0 blocks
==6866== possibly lost: 355,995,382 bytes in 2,276 blocks
==6866== still reachable: 1,065,944,397 bytes in 9,183 blocks
==6866== suppressed: 0 bytes in 0 blocks
==6866== Rerun with --leak-check=full to see details of leaked memory
==6866==
==6866== For counts of detected and suppressed errors, rerun with: -v
==6866== Use --track-origins=yes to see where uninitialised values come from
==6866== ERROR SUMMARY: 538 errors from 60 contexts (suppressed: 340 from 8)
Segmentation fault
(0026841)
David Gobbi   
2011-06-11 18:01   
Do you have VTK_USE_64BIT_IDS:BOOL=ON set in cmake? Your data set is large enough that it probably requires it.

There are two likely causes of this error:
1) 32-bit math where 64-bit math is required
2) the use of negative index values (negative indices are allowed in VTK but they are not very well tested)

Also, does this error only occur when you use multiple threads? So far it does not seem to be related to the original bug that you posted.
(0026866)
Dominik Szczerba   
2011-06-14 16:05   
After one day of testing, yes, using 64 bit ids seems to resolve the problem this time, even though the error message is identical to the original one. Many thanks for your support so far.
(0026916)
David Gobbi   
2011-06-30 07:57   
Fixed by commit e820d695c5deb0ea5336187508263e4479f5dd73
Change-Id: Ia8acc0957e4d21dd1f8a6822b9bf189ebd7d586f
merged on Fri, 27 May 2011