comp.lang.idl-pvwave archive: archive » Re: Releasing memory in IDL

Home » Public Forums » archive » Re: Releasing memory in IDL

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: Releasing memory in IDL [message #58222]

Wed, 23 January 2008 13:15

Paul Van Delst[1]
Messages: 1157
Registered: April 2002

Senior Member

Paul van Delst wrote:
> Jean H wrote:
>> Jaime wrote:
>>> Thanks Jean,
>>>
>>> it helped me... but I was forced to call heap_gc and delete a couple
>>> of arrays (a=0) at the end, but still inside, of the clumpfind
>>> function. After that I still needed to call heap_gc after clumpfind is
>>> called.
>>>
>>> It looks still strange to me that I should all this to get some memory
>>> back... is there a way to avoid the memory leak?
>>>
>>> Best,
>>> Jaime
>>
>> hum...
>> for regular variables (i.e. not pointers), they are released from
>> memory when you exit the pro or function... so setting "a=0" should
>> change the memory used IN the function, but should have no effect when
>> the program returns to a lower / main level. Indeed, this is correct
>> provided that a) the variable is not part of the argument of the
>> function, or b)the variable is not part of a common block.
>>
>> To avoid memory leak... well... pointers need to be well defined and
>> cleaned up!
>>
>> a = ptr_new(indgen(100000000000))
>> a = 0 ==> you just lost track of the indgen(100000000000) array!!! ...
>
> Not completely:
>
> IDL> x=ptr_new(lindgen(100))
> IDL> help, x
> X POINTER = <PtrHeapVar1>
> IDL> help, *x
> <PtrHeapVar1> LONG = Array[100]
> IDL> x=0
> IDL> help, x
> X LONG = 0
> IDL> print, ptr_valid()
> <PtrHeapVar1>
> IDL> y=ptr_valid(1,/cast)
> IDL> help, y
> Y POINTER = <PtrHeapVar1>
> IDL> help, *y
> <PtrHeapVar1> LONG = Array[100]
>
> Though, off the top of my head, I dunno how you would determine the
> pointer heap variable number programmatically.

Duh! I shoulda kept reading the docs before posting....

IDL> print, ptr_valid(count=c)
<PtrHeapVar1>
IDL> print, c
1

Report message to a moderator

Re: Releasing memory in IDL [message #58223 is a reply to message #58222]

Wed, 23 January 2008 13:12

Paul Van Delst[1]
Messages: 1157
Registered: April 2002

Senior Member

Jean H wrote:
> Jaime wrote:
>> Thanks Jean,
>>
>> it helped me... but I was forced to call heap_gc and delete a couple
>> of arrays (a=0) at the end, but still inside, of the clumpfind
>> function. After that I still needed to call heap_gc after clumpfind is
>> called.
>>
>> It looks still strange to me that I should all this to get some memory
>> back... is there a way to avoid the memory leak?
>>
>> Best,
>> Jaime
>
> hum...
> for regular variables (i.e. not pointers), they are released from memory
> when you exit the pro or function... so setting "a=0" should change the
> memory used IN the function, but should have no effect when the program
> returns to a lower / main level. Indeed, this is correct provided that
> a) the variable is not part of the argument of the function, or b)the
> variable is not part of a common block.
>
> To avoid memory leak... well... pointers need to be well defined and
> cleaned up!
>
> a = ptr_new(indgen(100000000000))
> a = 0 ==> you just lost track of the indgen(100000000000) array!!! ...

Not completely:

IDL> x=ptr_new(lindgen(100))
IDL> help, x
X POINTER = <PtrHeapVar1>
IDL> help, *x
<PtrHeapVar1> LONG = Array[100]
IDL> x=0
IDL> help, x
X LONG = 0
IDL> print, ptr_valid()
<PtrHeapVar1>
IDL> y=ptr_valid(1,/cast)
IDL> help, y
Y POINTER = <PtrHeapVar1>
IDL> help, *y
<PtrHeapVar1> LONG = Array[100]

Though, off the top of my head, I dunno how you would determine the pointer heap variable
number programmatically.

cheers,

paulv

Report message to a moderator

Re: Releasing memory in IDL [message #58224 is a reply to message #58223]

Wed, 23 January 2008 13:02

David Fanning
Messages: 11724
Registered: August 2001

Senior Member

Jaime writes:

> It looks still strange to me that I should all this to get some memory
> back... is there a way to avoid the memory leak?

Better programming always helps! Thanks for the chuckle. :-)

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.")

Report message to a moderator

Re: Releasing memory in IDL [message #58225 is a reply to message #58224]

Wed, 23 January 2008 12:35

Jean H.
Messages: 472
Registered: July 2006

Senior Member

Jaime wrote:
> Thanks Jean,
>
> it helped me... but I was forced to call heap_gc and delete a couple
> of arrays (a=0) at the end, but still inside, of the clumpfind
> function. After that I still needed to call heap_gc after clumpfind is
> called.
>
> It looks still strange to me that I should all this to get some memory
> back... is there a way to avoid the memory leak?
>
> Best,
> Jaime

hum...
for regular variables (i.e. not pointers), they are released from memory
when you exit the pro or function... so setting "a=0" should change the
memory used IN the function, but should have no effect when the program
returns to a lower / main level. Indeed, this is correct provided that
a) the variable is not part of the argument of the function, or b)the
variable is not part of a common block.

To avoid memory leak... well... pointers need to be well defined and
cleaned up!

a = ptr_new(indgen(100000000000))
a = 0 ==> you just lost track of the indgen(100000000000) array!!! ...
but it is still in memory!

Jean

Report message to a moderator

Re: Releasing memory in IDL [message #58226 is a reply to message #58225]

Wed, 23 January 2008 12:19

Jaime
Messages: 6
Registered: January 2008

Junior Member

Thanks Jean,

it helped me... but I was forced to call heap_gc and delete a couple
of arrays (a=0) at the end, but still inside, of the clumpfind
function. After that I still needed to call heap_gc after clumpfind is
called.

It looks still strange to me that I should all this to get some memory
back... is there a way to avoid the memory leak?

Best,
Jaime

>
> your clumpfind function may be leaking. Try calling heap_gc after the
> first run
>
> Jean

Report message to a moderator

Re: Releasing memory in IDL [message #58237 is a reply to message #58226]

Wed, 23 January 2008 09:51

Jean H.
Messages: 472
Registered: July 2006

Senior Member

jaime.e.pineda@gmail.com wrote:
> Hi,
>
> I am trying to run a function (clumpfind) several times with different
> parameters, however, after I call it once not enough memory is
> available. I checked with 'help, /memory' to find variables that I
> could destroy to release memory, without luck (see below).
>
> Is this the expected behavior of IDL? how can I release memory from
> the main function?
>
> Best,
> Jaime

your clumpfind function may be leaking. Try calling heap_gc after the
first run

Jean

Report message to a moderator

Re: Releasing memory in IDL [message #58321 is a reply to message #58225]

Wed, 23 January 2008 13:28

Jaime
Messages: 6
Registered: January 2008

Junior Member

I dug into the code and found that these variables are defined in a
COMMON block. Why are they still using memory after the program
finished? can they be destroyed altogether (e.g. common_block=0)?

Best,
Jaime

> hum...
> for regular variables (i.e. not pointers), they are released from memory
> when you exit the pro or function... so setting "a=0" should change the
> memory used IN the function, but should have no effect when the program
> returns to a lower / main level. Indeed, this is correct provided that
> a) the variable is not part of the argument of the function, or b)the
> variable is not part of a common block.
>
> To avoid memory leak... well... pointers need to be well defined and
> cleaned up!
>
> a = ptr_new(indgen(100000000000))
> a = 0 ==> you just lost track of the indgen(100000000000) array!!! ...
> but it is still in memory!
>
> Jean

Report message to a moderator

Previous Topic:	Re: multiple plots and pages to ps file
Next Topic:	Re: envi_get_data

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Oct 11 14:44:49 PDT 2025

Total time taken to generate the page: 1.43961 seconds