heap_free fatal error

#1 08-07-2008, 09:23 AM

Hi all,

I'm struggling with an IDL fatal error after calling heap_free. The
argument is a rather complex structure (hence the use of heap_free). I
started using ptr_free on some of the fields before the heap_free
call, but no luck so far (the structure is complex, so maybe I missed
some).

Did anyone observed heap_free crashing the IDL process and what was
the cause in your case?

I'm working on a WinXP 64-bit machine
IDL> print,!version
{ x86_64 Win32 Windows Microsoft Windows 7.0 Oct 25 2007 64 64}

Tried also with the 32bit version
{ x86 Win32 Windows Microsoft Windows 7.0 Oct 25 2007 32 64}

Thanks,

Wout

#2 08-07-2008, 10:30 AM

>Did anyone observed heap_free crashing the IDL process and what was
>the cause in your case?

I managed to extract the critical code:

n=30000l
p0=ptr_new({i:0l,next

tr_new()})
p=p0
for i=1l,n do begin
(*p).next=ptr_new({i:i,next

tr_new()})
p=(*p).next
endfor
heap_free,p0 ; FATAL ERROR

Is this a known bug?

#3 08-07-2008, 10:34 AM

Wox writes:

> I managed to extract the critical code:
>
> n=30000l
> p0=ptr_new({i:0l,next

tr_new()})
> p=p0
> for i=1l,n do begin
> (*p).next=ptr_new({i:i,next

tr_new()})
> p=(*p).next
> endfor
> heap_free,p0 ; FATAL ERROR
>
>
> Is this a known bug?

Now it is. :-)

It sure does ruin my day, IDL 7.0.1 on Windows 32-bit.

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")

#4 08-07-2008, 10:38 AM

On Thu, 07 Aug 2008 16:30:32 +0200, Wox <nomail@hotmail.com> wrote:

>>Did anyone observed heap_free crashing the IDL process and what was
>>the cause in your case?
>
>I managed to extract the critical code:
>
>n=30000l
>p0=ptr_new({i:0l,next

tr_new()})
>p=p0
>for i=1l,n do begin
> (*p).next=ptr_new({i:i,next

tr_new()})
> p=(*p).next
>endfor
>heap_free,p0 ; FATAL ERROR
>
>
>Is this a known bug?

I tried with IDL 6.2 on a Linux machine: no Fatal error
{ x86 linux unix linux 6.2 Jun 20 2005 32 64}

#5 08-07-2008, 11:03 AM

Seg faulted on Mac:

IDL> print, !version
{ i386 darwin unix Mac OS X 7.0 Oct 25 2007 32 64}

But runs OK on Linux:

IDL> print, !version
{ x86 linux unix linux 7.0 Oct 25 2007 32 64}

Mike
--
www.michaelgalloy.com
Tech-X Corporation
Software Developer II

Wox wrote:
>> Did anyone observed heap_free crashing the IDL process and what was
>> the cause in your case?
>
> I managed to extract the critical code:
>
> n=30000l
> p0=ptr_new({i:0l,next

tr_new()})
> p=p0
> for i=1l,n do begin
> (*p).next=ptr_new({i:i,next

tr_new()})
> p=(*p).next
> endfor
> heap_free,p0 ; FATAL ERROR
>
>
> Is this a known bug?

#6 08-07-2008, 11:11 AM

On Aug 7, 10:30*am, Wox <nom...@hotmail.com> wrote:
> >Did anyone observed heap_free crashing the IDL process and what was
> >the cause in your case?
>
> I managed to extract the critical code:
>
> n=30000l
> p0=ptr_new({i:0l,next

tr_new()})
> p=p0
> for i=1l,n do begin
> * * * * (*p).next=ptr_new({i:i,next

tr_new()})
> * * * * p=(*p).next
> endfor
> heap_free,p0 ; FATAL ERROR
>
> Is this a known bug?

Add
x86 Win32 Windows Microsoft Windows 6.4 Mar 23 2007 32 64

to the list of versions with this bug.
So far it looks like it's only Windows systems affected...

#7 08-07-2008, 12:04 PM

> Add
> x86 Win32 Windows Microsoft Windows 6.4 Mar 23 2007 32 64
>
> to the list of versions with this bug.
> So far it looks like it's only Windows systems affected...

as well as
IDL> print, !version
{ x86 Win32 Windows Microsoft Windows 6.3 Mar 23 2006 32 64}

Jean

#8 08-08-2008, 07:14 AM

Thanks guys. I reported the problem to ITTVIS.

#9 08-26-2008, 06:26 PM

Hey, guys,

This problem is due to a stack overflow in the code that cleans up the
heap. I submitted a fix and it should show up in a future version. A
quick band-aid until then is to increase the stack size for IDL. On
*nix systems, that's usually done with the "ulimit" command. On
Windows, I think you can do it with "editbin.exe". Here's a webpage
that has a little bit more detail on how to increase the stack size:
http://www.cs.nyu.edu/exact/core/doc/stackOverflow.txt

Unfortunately, this work around isn't a complete fix. You can still
run into this problem, but it will take a much larger object to hit
it. On OS X, setting the stack size to the maximum let me run the
OP's code with n=149000l.

Mark Eret
ITT Visual Information Solutions

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode