Failed to allocate memory
sep16
total) that fail to load on a Mac OSX machine with 32GB of RAM with
the message "Error reading image: Failed to allocate memory for
image.."
Starting the program from the command line, I can see the following
additional output when the error occurs:
InsightSNAP (19548,0xa075d500) malloc: *** mmap(size=2352463872)
failed (error code=12)
*** error: can't allocate region
We're using the pre-compiled binary, version 2.0.0. Activity Monitor
shows 22GB of free memory, but also implies that InsightSNAP is
running as a 32-bit program (it's not label as 64-bit in the list of
running programs, where some others are).
If this is the problem, then why is the memory limit under 2^32 (~4GB)?
Paul Yushkevich
SNAP has to allocate some memory in addition to the image itself.
Internally, the image is stored as short int, so temporarily memory
has to be allocated for two image volumes of the same size. That might
explain why we are running out of memory.
Do you have the capacity to build SNAP in 64bit mode? I would be
interested to see whether that solves the problem and also what the
peak memory usage would be.
Thanks
Paul.
> --
> You received this message because you are subscribed to the Google Groups "itksnap-users" group.
> To post to this group, send email to itksna...@googlegroups.com.
> To unsubscribe from this group, send email to itksnap-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/itksnap-users?hl=en.
>
>
--
Paul A. Yushkevich, Ph.D.
Assistant Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania
sep16
On Jul 12, 4:45 pm, Paul Yushkevich <pau...@mail.med.upenn.edu> wrote:
>
> Do you have the capacity to build SNAP in 64bit mode? I would be
> interested to see whether that solves the problem and also what the
> peak memory usage would be.
but only by downgrading libtiff from 4.0.0b6 to 3.9.4, which I can't
keep because I need the BigTIFF support. There was a change in the
tiff API (http://libtiff.maptools.org/v4.0.0.html) that breaks
compilation.
Is there a reason the pre-compiled Mac binary is not 64-bit? Aren't
most Macs 64-bit now?
Paul Yushkevich
It turns out that FLTK is the problem. Version 1.1.x does not support
64 bit Mac because it depends on Carbon, which is deprecated. So we
have to move ITK-SNAP to FLTK version 1.3 in order to build 64 bit on
the Mac. Unfortunately, there is not a stable 1.3 out there yet, so I
would prefer not to make the transition until it is released.
Paul.
Xinghua Lou
I am having the same problem when I tried to load a 1200 x 1200 x 320
raw data and the segmentation (both are unsigned short). My
workstation has 24G memory, which still seems to be still
insufficient. The OS is Ubuntu 32-bit.
What confuses me is that: only 20% memory was occupied after loading
the raw data, so the new layer of segmentation must have requested
much more memory than the first layer of raw data.
Thanks for your attention.
Best,
Xinghua.
Sebastian Moeller
On Sep 2, 2010, at 3:26 , Xinghua Lou wrote:
> Hello,
>
> I am having the same problem when I tried to load a 1200 x 1200 x 320
> raw data and the segmentation (both are unsigned short). My
> workstation has 24G memory, which still seems to be still
> insufficient. The OS is Ubuntu 32-bit.
Ubuntu 32-bit will allow user space programs at most 4GB of memory, more likely 3 or 2 GB. Your data files are
((1200 * 1200 * 320 * 2) / 1024) / 1024 = 878.90625 MB each, so you would need (878.90625 * 2) / 1024 = 1.71661376953 GB of memory for the data alone. Now I do not know what internal representation itksnap uses, but for 32 bit user space that is really pushing it. (And depending on the internal organization of itksnap these blocks of 880MB might have to be contigious). In short, you might want to try a 64 bit version of ubuntu and itksnap for that data.
Disclaimer, I have no knowledge of itksnap what so ever.
Best
Sebastian
>
> What confuses me is that: only 20% memory was occupied after loading
> the raw data, so the new layer of segmentation must have requested
> much more memory than the first layer of raw data.
>
> Thanks for your attention.
>
> Best,
> Xinghua.
>
> On Jul 9, 10:37 pm, sep16 <steven.peck...@gmail.com> wrote:
>> We have a stack of 298 images (1383 x 1472, raw, 32-bit float, ~2.3GB
>> total) that fail to load on a Mac OSX machine with 32GB of RAM with
>> the message "Error reading image: Failed to allocate memory for
>> image.."
>>
>> Starting the program from the command line, I can see the following
>> additional output when the error occurs:
>>
>> InsightSNAP (19548,0xa075d500) malloc: *** mmap(size=2352463872)
>> failed (error code=12)
>> *** error: can't allocate region
>>
>> We're using the pre-compiled binary, version 2.0.0. Activity Monitor
>> shows 22GB of free memory, but also implies that InsightSNAP is
>> running as a 32-bit program (it's not label as 64-bit in the list of
>> running programs, where some others are).
>>
>> If this is the problem, then why is the memory limit under 2^32 (~4GB)?
>
> --
> You received this message because you are subscribed to the Google Groups "itksnap-users" group.
> To post to this group, send email to itksna...@googlegroups.com.
> To unsubscribe from this group, send email to itksnap-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/itksnap-users?hl=en.
>
--
Sebastian Moeller
telephone: 626-395-6523 / 626-395-6616
fax: 626-395-8826
German GSM: 0 15 77 - 1 90 31 41
moe...@caltech.edu
Division of Biology
MC 114-96
California Institute of Technology
1200 East California Boulevard
CA 91125, Pasadena
USA