Subj : Re: Exception in SpiderMonkey v1.6 pr 6a
To   : netscape.public.mozilla.jseng
From : Rob Swindell
Date : Tue May 03 2005 01:48 am

> >>>js_Interpret(JSContext * 0x00a32010, unsigned char * 0x015f2913, long *
> >>>0x0012e4ec) line 2426 + 43 bytes
> >>
> >>In RC6a, this line is the starred one below:
> >>
> >>                 str = js_ConcatStrings(cx, str, str2);
> >>*               if (!str) {
> >>                     ok = JS_FALSE;
> >>                     goto out;
> >>                 }
> >>
> >>
> >>Have you hacked on jsinterp.c by any chance?
> >
> >
> > Nope. I have jsinterp.c rev 3.162, where line 2462 is starred below:
>
> $ cvs log jsinterp.c|grep RC6
>          JS_150_RC6a: 3.136.2.2
>          JS_150_RC6: 3.135
> $ cvs log jsinterp.c | grep 3.162
> revision 3.162
>
> So you must be using some random trunk checkout, not RC6a?

Apparently. I had no idea one couldn't rely on the validity of the string
returned from JS_GetImplementationVersion().

If it helps, the files appeared to have been checked out on February 21,
2005 1:25am, PST. If you wish, I can provide the output from "cvs stat",
which will identify, without question, the revision of each file used to
build this particular binary.

> >             /* Skip properties not owned by obj when looking from
origobj.
> > */
> > *          ok = OBJ_LOOKUP_PROPERTY(cx, origobj, fid, &obj2, &prop);
> >             if (!ok)
> >                 goto out;
> >
> > BTW, it'd be nice if the source files had CVS tags (e.g. "$Id: $")
> > indicating the revision.
>
> Those are bad form for people working from CVS, or at least were
> traditionally -- gratuitous differences from trunk, and when diffing
> against others' trees, and (most important) when generating patches.

I find them more useful than troublesome. <shrug>

> > I realize now that my js32.dll built from a CVS snapshot where
> > JS_GetImplementationVersion() returns "JavaScript-C 1.5 pre-release 6a
> > 2004-06-09", is not *actually* SpiderMonkey 1.5 PR 6a. I was under the
> > (apparently incorrect) assumption that cvs-mirror.mozilla.org only
contained
> > released source
>
> What gave you that idea?  It's a readonly mirror of cvs.mozilla.org.

The fact that the version string hasn't changed. I didn't actually review
the CVS commit logs or existing tags, or I would've realized that before. My
bad.

> > and that the string returned from
> > JS_GetImplementationVersion() would actually reflect the version built
from
> > the MAIN/HEAD rev. :-(
>
> That string is updated only when an RC is done.

Yeah, that's different from how I typically handle project version strings.
I change the version string immediately before and *after* a release and a
CVS tag is applied so it's obvious when a binary based on un-released source
is in use.

I would suggest un-released revisions of jsapi.c define the version string
something like:

    "JavaScript-C 1.5 post-6a unstable" or  "JavaScript-C 1.5 pre-6b
experimental"

while released revisions of jsapi.c continue to contain your traditional
release version labels, e.g.

    "JavaScript-C 1.5 pre-release 6b 2005-12-25".

I would also suggest parsing one or more CVS revision strings from CVS
keywords, something like:

    char revision[16];
    sscanf("$Revision: 1.4 $", "%*s %s", revision);

and including that in the version string, but you already stated your
opinion on the usefulness of CVS keywords.

> > Can I suggest tagging the released SpiderMonkey files with a common
label
> > (say "JS_LATEST_RELEASE") which will allow someone to get the latest
> > *released* version of the SpiderMonkey code?
>
> Released how?  A Mozilla alpha or beta milestone?

How about whenever the JS version string is modified?

> I don't think such a tag will help.  It begs questions, it does not
> answer them.  Use a known release tag if you like.
>
> > Now I have to decide if I should revert to the actual 1.5 pr 6a code or
use
> > the latest from CVS. Any suggestions?
>
> Since you are well after RC6a, you should try the trunk.  It's possible
> that one of the stack-pointer homing fixes to let the GC see operands
> that it should protect fixes your crash.  Let us know.

Unfortunately, I won't know for some time since I have no idea how to
reproduce the exception (it's occurred only once, and that was in a IRC
server that runs 24/7). And if/when the exception does occur again, the code
that I built from most likely won't be current any longer and I'll once
again be submitting stack traces and variable contents from a "random trunk
checkout". :-(

-Rob

.