Subj : Bug with MSVC Linker
To   : netscape.public.mozilla.jseng
From : "Michael Schneider" <mschneiderNOSPAM@ixos.ch>
Date : Tue Mar 18 2003 03:08 pm

Hey all!

After upgrading to SpiderMonkey 1.5 RC5 we had some big trouble. One of our
products keept crashing when a script was compiled. Besides of that, we were
only able to reproduce this error in a build without any debug symbols.
After some serious bug-searching we found the following:

A very simple ( ;) ) script defining a global variable (outside of a
function) crashes the engine:
--8<-------8<-------8<---
var xxx
--8<-------8<-------8<---

The reason for this is as follows:
- In jsparse.c on line 1916 the getters & setters are read
getter = clasp->getProperty;
setter = clasp->setProperty;

these pointers are used a bit later in a comparison on line 2045. by the
way, the getters and setters of our global objects are JS_PropertyStub().
this works just fine..

....and now to something completly different: the implementation of the
js_GetLocalVariable() function in jsinterp.c:551 was changed from RC4a to
RC5. The implementation is now just "return JS_TRUE".

and here comes the problem: the MSVC linker notices that the
JS_PropertyStub() and the js_GetLocalVariable() function have the same
signature and do exactly the same -> the linker "optimizes" one of the
implementations away (but only, if no symbols are used, because the symbols
do make the difference ;)), leftover remains the other. But of course both
methods have now the same address, what makes the comparison currentGetter
== js_GetLocalVariable become true!!!

because we are not in a function, fun is NULL ->  the parser crashes in
jsparse.c:2053 when dereferencing fun.

as quick workaround, we changed the implementation of js_getLocalVariable(),
so that the linker (or the compiler first) won't "optimize" it:

JSBool js_GetLocalVariable(JSContext *cx, JSObject *obj, jsval id, jsval
*vp)
{
    return cx != NULL ? JS_TRUE : JS_FALSE;
}

another approach would be to add the additional check for fun != NULL, but
I'm not sure if we would cover all possibilities with this fix.
what do you suggest?



greets,

Mike

.