[Insight-users] Resampling 64-bit crash

[Atwood, Robert C]

 Maybe I am being dumb here, but did you change 'dimension' to 3 as
well, or not? (Line 127)

 I don't think you can set 3d dimensions for a 2d filter? Maybe this
causes a compiler/OS dependent crash behaviour? If I do as you say
exactly, I get failure on output with weird messages (but maybe  you
can't put a 3d image in a png file!) 'Reason: Success' seems like kind
of a bad reason to abort.


Using linux RedHat , but also AMD64 Dual core processors, and 16 Gb of
physical RAM. 

[itk_example_build]$ ./ResampleBig BrainSliceBinary.png
BrainSliceBinaryOutput.png 0
terminate called after throwing an instance of 'itk::ExceptionObject'
  what():  /sources/local/ITK_cvs/Code/IO/itkPNGImageIO.cxx:503:
itk::ERROR: PNGImageIO(0xa00520): Error while writing Slice to file:
BrainSliceBinaryOutput.png
Reason: Success
Aborted








> -----Original Message-----
> From: insight-users-bounces+r.atwood=imperial.ac.uk at itk.org 
> [mailto:insight-users-bounces+r.atwood=imperial.ac.uk at itk.org]
>  On Behalf Of Florian Pierron
> Sent: 14 February 2007 14:06
> To: insight-users at itk.org
> Subject: [Insight-users] Resampling 64-bit crash
> 
> Dear ITK users and developers,
> 
> We need to resample big data and we decided to port our 
> application in 
> 64-bit version. We're currently working on Windows Server 2003, 
> Enterprise x64 Edition, Dual Core AMD Opteron and using 
> ITK-3-0 branch 
> with VC2005. Unfortunately our application crashes when trying to 
> resample big data.
> 
> We reproduced the crash with the ResampleImageFilter example 
> (D:\InsightToolkit-3.0.0\Examples\Filtering\ResampleImageFilte
> r.cxx) by 
> changing the size of the output image to be more than 3-4 GB:
> Line 279:    size[0] = 5 * 1000 * 1000;  // number of pixels along X
> Line 280:    size[1] = 1 * 1000;  // number of pixels along Y
> 
> We run this example by setting the working directory to 
> "D:\InsightToolkit-3.0.0\Testing\Data\Input" and the command line 
> arguments to
> "BrainSliceBinary.png BrainSliceBinaryOutput.png 0" (a random image I 
> found in the ITK folder).
> 
> 1) If I run this example with the modified size above (5 GB), 
> it crashes 
> immediately in:
> 
>   /** Set the pixel. */
>   inline void Set(TType & output, const TType & input) const
>     {output = input;}
> 
> with this call stack:
> 
>      ResampleImageFilter.exe!itk::DefaultPixelAccessor<unsigned 
> char>::Set(unsigned char & output=, const unsigned char & 
> input=0)  Line 
> 67 + 0x1d bytes
>      
> ResampleImageFilter.exe!itk::DefaultPixelAccessorFunctor<itk::
> Image<unsigned 
> char,2> >::Set(unsigned char & output=, const unsigned char & 
> input=0)  
> Line 77
>      
> ResampleImageFilter.exe!itk::ImageLinearIteratorWithIndex<itk:
> :Image<unsigned 
> char,2> >::Set(const unsigned char & value=0)  Line 106 + 0x47 bytes
>      
> ResampleImageFilter.exe!itk::ResampleImageFilter<itk::Image<unsigned 
> char,2>,itk::Image<unsigned 
> char,2>,double>::LinearThreadedGenerateData(const 
> itk::ImageRegion<2> & 
> outputRegionForThread={...}, int threadId=2)  Line 481
>      
> ResampleImageFilter.exe!itk::ResampleImageFilter<itk::Image<unsigned 
> char,2>,itk::Image<unsigned 
> char,2>,double>::ThreadedGenerateData(const 
> itk::ImageRegion<2> & outputRegionForThread={...}, int 
> threadId=2)  Line 192
>      ResampleImageFilter.exe!itk::ImageSource<itk::Image<unsigned 
> char,2> >::ThreaderCallback(void * arg=0x0000000002c2f4f8)  Line 282
>      
> ResampleImageFilter.exe!itk::MultiThreader::SingleMethodProxy(void 
> * arg=0x0000000002c2f4f8)  Line 748
>      msvcr80d.dll!_callthreadstartex()  Line 348 + 0x17 bytes
>      msvcr80d.dll!_threadstartex(void * 
> ptd=0x0000000002c3c8f0)  Line 331
> 
> 
> 2) If I change the size to be 2GB, it's running fine. The 
> limit between 
> crashing and not crashing seems to be between 2 and 3 GB 
> (with 8 threads).
> 
> 3) If I force the SetNumberOfTheads to 1, it doesn't crash 
> immediately 
> (I think it crashes later, but it's quite slow so most of the time I 
> killed it before). The funny thing is that when the number of 
> threads is 
> equal to 1:
> - if the size is 4 GB, then 4 GB of memory is allocated immediately
> - but if the size is 5 GB, only 700 MB is allocated
> - for 7 GB, 2.65 GB is allocated
> - for 10 GB, 1.4 GB is allocated (which is weirdly twice the 5GB)
> I have no idea if this is meaningful at all, I was just wondering if 
> there's a problem during memory allocation when the 4GB limit 
> is reached...
> 
> 
> Any ideas?
> 
> Cheers,
> Florian
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>