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

[Neil Weisenfeld]

Hi Ruben,

I haven't tried this yet with ITK and I don't think that ITK should need 
any changes, however in order to use more than 2GB of data on a x86_64 
machine, you have to specify (non-default) compiler options with either 
GCC or ICC.

See:

http://seldon.it.northwestern.edu/sscc/iccdoc/Release_Notes.htm

and

http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/i386-and-$

and search for "mcmodel."


I don't believe that gcc earlier than 4.x supports 64-bit pointers at all.

If you're linking to ITK statically, then you would need to rebuild ITK 
with the proper memory model, also.

If there's a fundamental ITK problem here, then hopefully someone else 
will chime in, but I don't think that's the case.


Regards,
Neil






On Mon, 9 Apr 2007, Ruben Schilling wrote:

> 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
>> 
>> 
>