[Insight-users] crashes N-D Linear Time Exact Signed Euclidean Distance Transform
Oleksandr Dzyubak
adzyubak at gmail.com
Thu May 29 17:01:50 EDT 2008
Hi Bill,
Thanks for a hint. I will try it.
I have already thought of a hardware as of a reason since
I found on the Internet that memory issue has been solved for gcc 4.1
and higher.
I heard that in some heavy scientific runs Intel CPUs can produce
similar failure.
Since I have I-32, I did some tests using both memtester and cpuburn
utilities.
http://pyropus.ca/software/memtester/old-versions/memtester-4.0.8.tar.gz
http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz
My box has passed all the tests so I have to try it on non-Intel based CPU.
Alex
Bill Lorensen wrote:
> Oleksandr,
>
> If you have valgrind on your linux box, try running it. It can find
> some tricky memory problems.
>
> Bill
>
> On Thu, May 29, 2008 at 12:08 PM, Oleksandr Dzyubak <adzyubak at gmail.com> wrote:
>
>> Hi Nick,
>>
>> I did quick search and found that gcc 4.2.xx is more strict in terms of
>> memory use.
>> Keeping this in mind, I did a test with my 3D images on a machine with gcc
>> 3.4.6
>> where your program worked well with the images provided in the archive.
>>
>> Your image SquareBinary201.hdr (size 157.8 KB ) info.
>>
>> General Image Information:
>>
>> number : 1ifname : SquareBinary201.hdr
>> ofname :
>> iformat : 9 (= Analyze )
>> modality : 20045 (= NM)
>> rawconv : 0 (= No)
>> endian : 1 (= Little)
>> compression : 0 (= None)
>> mwidth : 201
>> mheight : 201
>> bits : 32
>> type : 6 (= Int32)
>> dim[0] : 4 (= total in use)
>> dim[1] : 201 (= pixels X-dim)
>> dim[2] : 201 (= pixels Y-dim)
>> dim[3] : 1 (= planes | (time) slices)
>>
>>
>> My image t_Idx_300_260_0_p150_p240.hdr (size 23.7 MB) info.
>>
>> ifname : t_Idx_300_260_0_p150_p240.hdr
>> ofname :
>> iformat : 9 (= Analyze )
>> modality : 20045 (= NM)
>> rawconv : 0 (= No)
>> endian : 1 (= Little)
>> compression : 0 (= None)
>> General Image Information
>> number : 100
>> mwidth : 565
>> mheight : 440
>> bits : 8
>> type : 3 (= Uint8)
>> dim[0] : 4 (= total in use)
>> dim[1] : 565 (= pixels X-dim)
>> dim[2] : 440 (= pixels Y-dim)
>> dim[3] : 100 (= planes | (time) slices)
>>
>>
>> So when I ran a code on my 3D image I got a program crash with the error
>> below.
>>
>> *********** Error ********
>>
>> [rdzyubak at DesktopBSD: /3DSegmentation_Imgs]$
>> ./SignedMaurerDistanceMapImageFilterTest t_Idx_300_260_0_p150_p240.hdr
>> test.hdr
>> terminate called after throwing an instance of 'itk::ExceptionObject'
>> what():
>> /usr/local/include/InsightToolkit/Common/itkImportImageContainer.txx:193:
>> Failed to allocate memory for image.
>> Abort trap: 6
>>
>>
>>
>>
>> Oleksandr Dzyubak wrote:
>>
>>> Hi Nick,
>>>
>>> Thanks for your quick response,
>>>
>>> Sorry for incorrectness in my previous email. I did use the program in a
>>> proper way
>>> but the error stays the same (see below). The compilers I am using gcc
>>> 4.2.3 and 4.1.2 (Debian).
>>> Unfortunately at the moment I do not have a box with gcc 4.0.1 so I cannot
>>> test it.
>>> But as I said before when running gcc 3.4.6 (FreeBSD 6.3), I do not
>>> experience
>>> any problem and the code works fine.
>>>
>>> Alex
>>>
>>> *********** Error ***
>>>
>>> dzyubak at debian: /Images$ ./SignedMaurerDistanceMapImageFilterTest
>>> SquareBinary201.hdr test.hdr
>>> *** glibc detected *** malloc(): memory corruption: 0x0816ab90 ***
>>> Aborted
>>> dzyubak at debian: /Images$
>>>
>>>
>>> Nick Tustison wrote:
>>>
>>>> Hi Alex,
>>>>
>>>> I haven't encountered the errors below although I wrote and tested the
>>>> classes on my macbook using gcc 4.0.1. I know a number of other
>>>> people who have had success on a variety of platforms. From the
>>>> error message that you provided below, it doesn't appear that you are
>>>> specifying an output image file name (which the test code expects).
>>>> Could that be the source of your difficulties?
>>>>
>>>> Nick
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 28, 2008 at 3:14 PM, Oleksandr Dzyubak <adzyubak at gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>> Dear ITKers,
>>>>>
>>>>> I tried to use N-D Linear Time Exact Signed Euclidean Distance Transform
>>>>> from IJ.
>>>>>
>>>>> http://insight-journal.org/midas/handle.php?handle=1926/171
>>>>>
>>>>> Compilation went fine and I got a brand new and very nice looking
>>>>> executable.
>>>>> However when I tried to run it on the example images provided in the
>>>>> distribution archive,
>>>>> the program keeps crashing with the memory corruption error ( see error
>>>>> below).
>>>>>
>>>>> Am I missing something?
>>>>> Have anybody tried that algorithm implementation?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Alex
>>>>>
>>>>> PS.
>>>>> Just read a note about a big change in gcc when go from 3.x to 4.x
>>>>> and did some preliminary tests.
>>>>>
>>>>> Debian Lenny gcc 4.2.3 -- compiles fine; test run crashes.
>>>>> Debian Etch gcc 4.1.2 -- compiles fine; test run crashes.
>>>>> FreeBSD 6.3 gcc 3.4.6 -- compiles fine; test run works fine.
>>>>>
>>>>> In this case, was N-D Linear Time Exact Signed Euclidean Distance
>>>>> Transform
>>>>> written for some C++ flavour?
>>>>>
>>>>>
>>>>> *********************** Errors ********
>>>>>
>>>>> dzyubak at debian: /Images$ ls
>>>>> binaryPhantom.hdr peep0_seg01_out.img
>>>>> binaryPhantom.img SignedMaurerDistanceMapImageFilterTest
>>>>> binaryPhantom_out.hdr SquareBinary201.hdr
>>>>> binaryPhantom_out.img SquareBinary201.img
>>>>> peep0_seg01.hdr SquareBinary201_out.hdr
>>>>> peep0_seg01.img SquareBinary201_out.img
>>>>> peep0_seg01_out.hdr
>>>>> dzyubak at debian: /Images$ ./SignedMaurerDistanceMapImageFilterTest
>>>>> SquareBinary201.hdr
>>>>> *** glibc detected *** malloc(): memory corruption: 0x08176b90 ***
>>>>> Aborted
>>>>>
>>>>> _______________________________________________
>>>>> Insight-users mailing list
>>>>> Insight-users at itk.org
>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
More information about the Insight-users
mailing list