Subj : Re: JS_ASSERT in js_MarkScriptFilename() To : netscape.public.mozilla.jseng From : "Edward Chan" Date : Thu Feb 19 2004 06:10 pm Ok, some more info. After some debugging, I'm getting closer to understanding what's going on. This is what I'm seeing, I'm in the process of doing a gc. While enumerating gcRootsHash, JS_DHashTableEnumerate(&rt->gcRootsHash, gc_root_marker, cx); it has found a JSScript object that it is marking. However, when it gets to js_MarkScript(), script->filename is bad. The reason it is bad is because a previous gc, has removed it from script_filename_table, and freed it. So I have a few questions: When filename is removed from script_filename_table, and freed, do you null out script->filename for all the script objects that are pointing to that address in memory that was just freed? It seems like this is not the case. But shouldn't it be? But if so, how do you know which script objects are pointing to that filename? I don't see where this is being maintained. Ed "Edward Chan" wrote in message news:c13lo2$6271@ripley.netscape.com... > Hi Brendan, > > I noticed that in js_SweepScriptFilenames(), script_filename_table is being > accessed unprotected. Is that ok? > > Here are some more data points. > > I have a break point set in js_MarkScript(), just before calling > js_MarkScriptFilename() where the JS_ASSERT happens. > > When JS_GC() is called, I hit the break point a few times. When I check > script->filename, it's valid. But each time it is a different script object > (I only have 1 script involved in this test, but it looks like the JS engine > is creating multiple JSScript objects, which I assume to be fine). When I > look back at the call stack, I see that it is coming from > > JS_DHashTableEnumerate() > JS_GC > > There's a comment before the call to JS_DHashTableEnumerate(), that says, > "Mark phase." > > Then, when I hit my breakpoint in js_MarkScript where script->filename is > bad, I see that I am coming from, > > js_SweepScriptFilenames() > JS_GC > > > Can you make any more sense out of this? > > > "Edward Chan" wrote in message > news:c13b38$sed1@ripley.netscape.com... > > We're not using JS_BeginRequest/JS_EndRequest. The reason is, we only > have > > 1 thread running. Basically, this is the structure that we use. > > > > We have the notion of a sandbox. Each sandbox has its own runtime, with a > > single context, and a single execution thread. But we can have more than > > one of these sandboxes running at the same time. But as I said, they > don't > > share the same runtime, context, or execution thread. However, I think > this > > came up before in another issue you helped me with, that required defining > > JS_THREADSAFE, eventhough we thought we didn't need it due to the single > > threaded nature of each sandbox. So we did that a while back, and > > everything is running fine. > > > > So let me get back to the order in which we do things. The current order > is > > this: > > > > JS_CompileFileHandle > > JS_ExecuteScript > > JS_DestroyScript > > > > Should we be doing this instead: > > > > JS_CompileFileHandle > > JS_NewScriptObject > > JS_AddRoot > > JS_ExecuteScript > > JS_RemoveRoot > > JS_DestroyScript > > > > And my next question is when is it ok to call JS_DestroyScript? Is it ok > to > > destroy the script after executing it as we are doing here? > > > > > > > > "Brendan Eich" wrote in message > > news:40351D8D.3040607@meer.net... > > > Edward Chan wrote: > > > > > > >Hi Brendan, > > > > > > > >Thanks for the speedy reply. Unfortunately, I don't have the assert in > > the > > > >debugger anymore, so I can't check if script->object exists. I'll > check > > for > > > >this if I hit this again. > > > > > > > >But basically, this is what I'm doing: > > > > > > > >1. call JS_CompileFileHandle() and get a JSScript*. > > > >2. call JS_ExecuteScript() > > > >3. call JS_DestroyScript() > > > > > > > >So basically, compile, execute, destroy. After executing the script, > we > > > >destroy it cuz we never use it again. Is there anything wrong with > this > > > >sequence? I'm not calling JS_NewScriptObject. And oddly, we've never > > run > > > >into this using rc5. > > > > > > > > > > > > > > Maybe you ran into something like it (script_filename_table is new in > > > RC6) and didn't crash. It's intermittent, clearly; it depends on memory > > > pressure and other conditions that might govern whether a GC runs from > > > within JS_ExecuteScript, or races with it on another thread. > > > > > > Are you using JS_BeginRequest and JS_EndRequest around the above three > > > steps? > > > > > > A script being executed will be protected by its stack frame from being > > > GC'd, so will be marked (so its filename will be marked too). That > > > suggests that the GC is happening on another thread, and you are not > > > bracketing 1-3 above with a request; or possibly the GC is nesting > > > between steps 1 and 2 or 2 and 3. Can you show more code? > > > > > > /be > > > > > > .