View Issue Details [ Jump to Notes ] [ Print ]
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 
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.
ProjectTBD
Typeincorrect functionality
Attached Filesbz2 file icon data.tar.bz2 [^] (125,146 bytes) 2011-05-27 07:19

 Relationships

  Notes
(0026633)
David Gobbi (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
2011-06-30 07:57

 Fixed by commit e820d695c5deb0ea5336187508263e4479f5dd73
Change-Id: Ia8acc0957e4d21dd1f8a6822b9bf189ebd7d586f
merged on Fri, 27 May 2011

 Issue History
Date Modified Username Field Change
2011-05-27 07:19 Dominik Szczerba New Issue
2011-05-27 07:19 Dominik Szczerba File Added: data.tar.bz2
2011-05-27 09:34 David Gobbi Assigned To => David Gobbi
2011-05-27 09:34 David Gobbi Status backlog => tabled
2011-05-27 09:36 David Gobbi Note Added: 0026633
2011-05-27 09:36 David Gobbi Status tabled => @40@
2011-05-27 12:04 Dominik Szczerba Note Added: 0026634
2011-05-27 12:13 David Gobbi Note Added: 0026635
2011-05-28 12:01 Dominik Szczerba Note Added: 0026645
2011-05-28 13:08 David Gobbi Note Added: 0026646
2011-06-10 16:05 Dominik Szczerba Note Added: 0026826
2011-06-10 16:25 David Gobbi Note Added: 0026827
2011-06-11 06:11 Dominik Szczerba Note Added: 0026832
2011-06-11 12:47 David Gobbi Note Added: 0026835
2011-06-11 17:08 Dominik Szczerba Note Added: 0026839
2011-06-11 17:21 Dominik Szczerba Note Added: 0026840
2011-06-11 18:01 David Gobbi Note Added: 0026841
2011-06-14 16:05 Dominik Szczerba Note Added: 0026866
2011-06-30 07:57 David Gobbi Project => TBD
2011-06-30 07:57 David Gobbi Type => incorrect functionality
2011-06-30 07:57 David Gobbi Note Added: 0026916
2011-06-30 07:57 David Gobbi Status backlog => tabled
2011-06-30 07:57 David Gobbi Resolution open => fixed
2011-06-30 07:59 David Gobbi Status tabled => closed

Copyright © 2000 - 2018 MantisBT Team