[Insight-users] Segmentation fault with 2.2G data but not with smaller subset

[lynx.abraxas at freenet.de]

Hello!


I  modified  the code to read in raw-files now because I got to know that TIFF
can have troubles storing more than 2GB data. ImageJ seems to be able to  save
it though.

With  the  new  code I read in 16-bit data from the start (which is a bit of a
waste for binary data).  The  problem  is  that  the  masking  filter  is  not
accepting a mask of 8-bit and a file to mask of 16-bit.


Anyway, with the 4.4GB dataset I get the following:

time ~/itk/watershed07/watershed07 zs_gauss-0.5-9_ru_16bit.raw zs_gauss-0.5-9_ru_ws_113101.tif 1 1 3 1 0 1 1550 1549 950
signed danielson distance map...
Morphological watershed...
Creating output...
terminate called after throwing an instance of 'itk::ExceptionObject'
  what():  /home/ttd/localusr/include/InsightToolkit/Common/itkImportImageContainer.txx:188:
Failed to allocate memory for image.
Abgebrochen

real    3m22.319s
user    3m11.452s
sys     0m10.645s
 

top tells me that watershed07 did not use more than 25% of the available RAM (~50GB).
watershed07 though seems to be 64-bit:

file ~/itk/watershed07/watershed07
/home/ttd/itk/watershed07/watershed07: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamicall
y linked (uses shared libs), not stripped

ldd ~/itk/watershed07/watershed07
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b125abcc000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b125add0000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b125afeb000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b125b1f0000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b125b443000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b125b74b000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b125b95a000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b125a9af000)


So I wonder why it can not allocate enough memory although there is still 75% left.

Thanks for all Your help!
Lynx



On 10/08/09 10:52:27, Bradley Lowekamp wrote:
> This looks like the following bug:
>
> http://www.itk.org/Bug/view.php?id=6840
>
> I have been meaning to fix this, I'll start.
>
> In the mean time you should be able to get around this bug, by not  
> performing a conversion in the Reader. In this case your file is of type 
> unsigned char, but you are reading it as a unsigned short with an  
> itk::ImageFileReader<Image<unsigned short, 3> >.  Followed this reader  
> by a CastImageFilter or a custom adaptor, should enable you to by pass  
> this bug.
>
> Brad
>
>
> On Aug 10, 2009, at 10:38 AM, Sean McBride wrote:
>
>> On 8/10/09 8:41 AM, lynx.abraxas at freenet.de said:
>>
>>> Is there some way  to
>>> find out if itk is compiled as 64-bit?
>>
>> Your backtrace suggests you are indeed running as 64 bit:
>>
>> (gdb) where
>> #0  0x00000000005916f0 in itk::ConvertPixelBuffer<unsigned char,
>> unsigned short, itk::DefaultConvertPixelTraits<unsigned short>
>>> ::ConvertGrayToGray ()
>> #1  0x00000000005d25be in itk::ConvertPixelBuffer<unsigned char,
>> unsigned short, itk::DefaultConvertPixelTraits<unsigned short>  
>> >::Convert ()
>>
>> Those addresses are 64 bit.
>>
>> It could well be a bug in ITK... since you know how to use gdb, I'd
>> suggest looking for some code that does something like use a small
>> integer type (like int) for storing sizes.
>>
>> -- 
>> ____________________________________________________________
>> Sean McBride, B. Eng                 sean at rogue-research.com
>> Rogue Research                        www.rogue-research.com
>> Mac Software Developer              Montréal, Québec, Canada
>>
>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-users
>
> ========================================================
> Bradley Lowekamp
> Lockheed Martin Contractor for
> Office of High Performance Computing and Communications
> National Library of Medicine
> blowekamp at mail.nih.gov
>
>