Subj : Re: JS_ASSERT in js_MarkScriptFilename()
To   : netscape.public.mozilla.jseng
From : "Edward Chan" <echan@macromedia.com>
Date : Thu Feb 19 2004 04:49 pm

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" <echan@macromedia.com> 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" <brendan@meer.net> 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
>
>

.