Subj : Re: automatic variable that holds JSAtom* in JS_DefineFunction()  is not GC protected.
To   : netscape.public.mozilla.jseng
From : myngs@hotmail.com (itaj sherman)
Date : Mon Mar 17 2003 02:45 pm

> JS_PUBLIC_API(JSObject *)
> JS_NewScriptObject(JSContext *cx, JSScript *script)
> {
>     JSObject *obj;
> 
>     /*
>      * We use a dummy stack frame to protect the script from a GC caused
>      * by debugger-hook execution.
>      *
>      * XXX We really need a way to manage local roots and such more
>      * XXX automatically, at which point we can remove this one-off hack
>      * XXX and others within the engine.  See bug 40757 for discussion.
>      */
>     JSStackFrame dummy;
> 
> If it doesn't, you need to upgrade your engine.

all the versions i use have this

 
> Can you define JS_PARANOID_REQUEST in jsapi.c near the top, and make 
> sure all API calls are running inside of requests?  Sorry if you already 
> did that (recently) and verified.

i always have JS_PARANOID_REQUEST, even added CHECK_REQUEST() to some
JS_*() that didn't have it like JS_SetPrivate() (and others, i can't
remember now). - BTW in some of the versions that i downloaded, there
were CHECK_REQUEST(cx) in some JS_*() that didn't have 'cx' parameter
(think JS_GetStringBytes) and i had to remove these lines.

> 
> If an atom is being swept by the GC, then it was not marked.  If it was 
> not marked, then either it was not reachable from the rooted script 
> object, or the script mapping the atom was not reachable from a rooted 
> object.  I don't see another possibility.
> 
> You should log all scripts marked by the GC (js_MarkScript) on each run 
> (log their addresses), log the script you compile in compileinthread.cpp 
> by its address too, reproduce the crash, and see if the GC marked that 
> script.  If it did not, then the GC ran when there was no rooted script 
> object protecting the script.  If it did mark the script and its atoms, 
> then the sweeper collected an atom that should have been marked -- that 
> suggests a problem where atom mark bits get cleared somehow, perhaps by 
> a racing or nesting GC.
> 
> Anyway, it should be easy to answer the question, if you flush the log 
> file or write synchronously to it: did the last GC to run, the one that 
> swept the atom you crash on in js_Interpret, actually mark the script 
> that you're executing in js_Interpret at the time of the crash?
> 

i'll work on that and let you know what i get.

thanks
itaj

.