Subj : Re: question: memory allocated by JS_Enumerate().
To   : netscape.public.mozilla.jseng
From : jp
Date : Fri May 06 2005 12:46 am

thanks, especially the answer on my question 4. I will go through my 
code to check if i missed anything else.

Brendan Eich wrote:
> jp wrote:
> 
>> Did a search in the list, didn't find anything.
>>
>> I have been hunting a memory leak for the past 3 days. Now i suspect 
>> that the memory allocated by JS_Enumerate() will not be release unless 
>> you call JS_DestroyIdArray(). So here's my questions:
>>
>> 1. Do I need to use JS_DestroyIdArray() to release the pointer 
>> returned by JS_Enumerate()?
> 
> 
> 
> Yes, of course -- but the stupid API doc doesn't say so.  Still, it's 
> pretty clear from the signatures.
> 
> 
>> 2. It seems, if I don't use JS_DestroyIdArray() to release the 
>> pointer, the memory will not be released even after I destroy the 
>> context and runtime. Is that true?
> 
> 
> 
> Yes.
> 
> 
>> 3. If 2 is true, I think it is very easy for users to forget to call 
>> JS_DestroyIdArray(). At least the document should emphasis it.
> 
> 
> 
> You're right, I'll fix it.
> 
> 
>> 4. Is there any other situation similar to this where I should use 
>> extra caution? I was really scared by this. :) It took my team 3 days 
>> to figure it out.
> 
> 
> 
> The manually allocated and freed, or created and destroyed, data 
> structures in the API are JSRuntime, JSContext, JSIdArray, 
> JSExceptionState, and -- unless you wrap a script with an object using 
> JS_NewScriptObject, JSScript.
> 
> 
>> 5. It would be nice to have a way to find out how much memory the 
>> runtime is using.
> 
> 
> 
> It would, but it's not as easy as it seems.  Instrumenting a wrapped 
> malloc may be the only way, and even then some strings handed off to the 
> GC heap may not be counted properly.
> 
> /be

.