Subj : Re: automatic variable that holds JSAtom* in JS_DefineFunction() To : itaj sherman From : brendan@meer.net (Brendan Eich) Date : Thu Mar 13 2003 04:51 pm itaj sherman wrote: >i think the JS_AddNamedRoot( rCx, &aRootObject ) always happened because i >asserted the value of aRootObject just the line before. i changed to alway >do JS_AddNamedRoot() anyway, and asserting the return value - it's always >JS_TRUE. > Right, I was sure that wasn't a problem so much as a lack of symmetry and less than best practice. >the inner block scope aGuardX2 is there because i once tried to add a lock >that allows only one thread to compile at a time would stop the bug. in >order to do that i had to suspend-resume the GC request while waiting on >sJSCompileLock to avoid AB-BA deadlock. in fact this only made the bug occur >much faster (100 times faster or so), so i left it there. >actually the lock on sJSCompileLock is not needed anymore, so i disabled >that line (you can do that too), but if i don't leave the suspend-resume >(and then aGuardX2 needed too) the bug will not happen - or will in only >very long time, i ran this program this way for 2 days (if i remember right) >once and it didn't crash. > > This all just changes the odds of a race of some sort, but it doesn't help find the bug, as far as I can tell. 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. 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? /be .