[Insight-users] Re: Re: Re: DeformableRegistration8.cxx std::bad_alloc

[Ruben Schilling]

Hi again,

I believe, that I might have found the issue myself possibly. When I  
use 10% of all voxels for sampling such as in line 335 in  
DeformableRegistration8.cxx of release 3.2.0, which is

   const unsigned int numberOfSamples = fixedRegion.GetNumberOfPixels 
() / 10;

then I get the bad_alloc as described. Changing the default example  
to only use 5% of the voxels i.e.

const unsigned int numberOfSamples = fixedRegion.GetNumberOfPixels 
() / 20;

solved the memory bug, my app is up and running now using about 3  
GBytes of memory. Usually I would blame it to 32bit applications now,  
but mine (and I also checked part of the ITK libraries for it) are 64  
bit (as is the system, where I run it). Thus I would assume now, that  
maybe either the const unsigned int above or some other int pointer  
would be guilty of throwing a bad_alloc, because the pointer is not  
able managing addesse space requiring more than 32 bits. Do you agree  
to this? To what degree is ITK capable (I mean of course capable from  
scratch, without modifications to the code!) of handling more than  
32bit memory? Would I need to change some pointers of ITK to handle  
some large volumes? My images have up to 90,000,000 voxels.

Best
Ruben



Anfang der weitergeleiteten E-Mail:

> Hi Luis,
>
> I just came back to the registration issue. I ran  
> DeformableRegistration8 from gdb by typing
>
> gdb DeformableRegistration8
>
> afterwards I ran the program from the gdb prompt with my inputfiles  
> like this
>
> >> run fixedImage.tif movingImage.tif outputImage.tif
>
> I don't know, if there is a way to get more details from gdb about  
> the running program, but so far I got this from gdb:
>
> [Thread debugging using libthread_db enabled]
> [New Thread 47202034567056 (LWP 24727)]
>
> Starting Registration
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  St9bad_alloc
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 47202034567056 (LWP 24727)]
> 0x00002aee143e55ed in *__GI_raise (sig=24727) at ../nptl/sysdeps/ 
> unix/sysv/linux/raise.c:67
> 67      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or  
> directory.
>         in ../nptl/sysdeps/unix/sysv/linux/raise.c
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20070409/ba34689c/attachment.html