[Insight-developers] how to detect pixel allocation failure ?

Simon Warfield warfield at crl.med.harvard.edu
Tue Mar 21 14:18:32 EST 2006


Peter Cech wrote:
> The problem might be elsewhere. ValarrayImageContainer just performs
> interface forwarding to std::valarray. The method Reserve() just calls
> std::valarray::resize(). I'm not very familiar with this class, so I
> looked up the description
> (http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=valarray.html&m=valarray#valarray::resize)
>
>    "void resize(size_t newsize);
>     void resize(size_t newsize, const Ty&val);
>
>     The member functions both ensure that size() henceforth returns
>     newsize. If it must make the controlled sequence longer, the first
>     member function appends elements with value Ty(), while the second
>     member function appends elements with value val. To make the
>     controlled sequence shorter, both member functions remove and delete
>     elements with subscripts in the range [newsize, size()). Any
>     pointers or references to elements in the controlled sequence are
>     invalidated."
>
> It looks like the documentation for Reserve() is wrong and not only
> the whole array is allocated but also initialized. Could it be that
> a pointer/iterator invalidated by resize() is used?
>   

I did some more digging into the issue.  I looked at how the resize is 
implemented.  On my system, the call eventually turns into a standard 
C++ 'new' request done in libstdc++.
This should raise a bad_alloc exception if it goes wrong.

Indeed, I did find if I tried to allocate a truly large amount of 
memory, I would get a bad alloc exception.
I'm not sure why it would be that sometimes I get the bad_alloc 
exception, and sometimes I get a seg fault using the result.

  It does seem the documentation for Reserve() is wrong.

> Peter
>
> On Wed, Mar 15, 2006 at 16:50:50 -0500, Miller, James V (GE, Research) wrote:
>   
>> In my experience, it is hard to know whether an allocation fails.
>>
>> For instance, on multi-tiered memory systems like what SGI uses, 
>> the system always says the allocation succeeds and assumes that
>> by the time you try to access the memory it will be available
>> (because you would have freed somethingelse).  So a memory allocation
>> doesn't fail until you try to read/write to the memory.
>>
>> That being said, if we can detect failure on some systems we should
>> try to report it. The problem then becomes: what do you do if an allocation
>> fails?  How can ITK or the application recover?
>>
>> Jim
>>
>>
>>
>> -----Original Message-----
>> From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
>> [mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
>> Of Simon Warfield
>> Sent: Wednesday, March 15, 2006 12:10 PM
>> To: Insight-developers
>> Subject: [Insight-developers] how to detect pixel allocation failure ?
>>
>>
>>
>> I have some code that runs fine on a 64 bit workstation but fails with a 
>> segmentation fault on a 32 bit workstation.
>>
>> It turns out this code is allocating a 4D image of size 256x256x40x208 
>> pixels.
>>
>> The code fails in a call to FillBuffer(0) when after a certain number of 
>> pixels (*m_Buffer)[i] stops being a valid container.
>>     
>>> Size of the LargestPossibleRegion
>>> 256 256 46 208
>>> About to call W->FillBuffer(0)
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread -1208133952 (LWP 5008)]
>>> 0x080ea098 in itk::Image<double, 4u>::FillBuffer (this=0x981d730,
>>>     value=@0xbfe998b8)
>>>     at 
>>> /opt/i386/pkgs/itk/2.4.1/gcc-release/include/InsightToolkit/Common/itkImage.txx:83
>>> 83          (*m_Buffer)[i] = value;
>>> (gdb) print i
>>> $1 = 90178047
>>>       
>> The buffer is allocated through AllocateOutputs() which ultimately calls
>> itk::ValarrayImageContainer<TElementIdentifier, TElement>::Reserve()
>>
>> It turns out that Reserve() is not guaranteed to allocate the pixels as 
>> requested.  The documentation says Reserve does the following:
>>     
>>> Tell the container to allocate enough memory to allow at least as many 
>>> elements as the size given to be stored. This is NOT guaranteed to 
>>> actually allocate any memory, but is useful if the implementation of 
>>> the container allocates contiguous storage. Definition at line 112 
>>> <http://www.itk.org/Doxygen/html/itkValarrayImageContainer_8h-source.html#l00112> 
>>> of file itkValarrayImageContainer.h 
>>> <http://www.itk.org/Doxygen/html/itkValarrayImageContainer_8h-source.html>.
>>>       
>> The API for itk::Image->Allocate() is for Allocate() to return void, 
>> whether or not allocate succeeds.
>>
>> I wonder if it should instead return a boolean indicating success or 
>> failure of the Allocate() operation ?
>> Is there some other means to determine if Allocate() was successful ?
>>
>> --
>> Simon
>>
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>     
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>   


-- 
Simon K. Warfield, Ph.D.        warfield at crl.med.harvard.edu
Phone: 617-732-7090                      FAX:   617-582-6033
Associate Professor of Radiology,     Harvard Medical School
Director, Computational Radiology Laboratory
Departments of Radiology at Children's Hospital and
Brigham and Women's Hospital,
Thorn 329, Dept Radiology,  Brigham and Women's Hospital
75 Francis St, Boston, MA, 02115
MA 280, Dept Radiology, Children's Hospital Phone: 617-355-4566



More information about the Insight-developers mailing list