Subj : Re: crash in JS_NewContext
To   : Weiyang Zhou
From : Brendan Eich
Date : Wed Sep 07 2005 03:29 pm

Weiyang Zhou wrote:
> We are using mips-elf-gcc (GCC) 3.2.
> 
> We really don't think it is the compiler's problem because the ALIGN macro 
> is doing the things it suppose to do.

I agree, but since you asked what the purpose of the macro is, I thought 
I'd point out that it's overallocating a stack buffer so that no matter 
its alignment, a JSString-sized piece of the buffer can be found using 
that macro, and used as a temporary JSString (not a GC-allocated one) 
just within jsatom.c.

> Here are the values from the sprintf statement:
> 
> 807ef884 807ef888 8 8 4
> 
> You can see str is shifted to 8 bytes boundary  from the start address of 
> buf.

That's good to have verified, thanks.

>>>Then it won't crash during the initialization. You can see the debug code 
>>>doesn't do anything significant except it uses the stack. But it still 
>>>crashes when I start using JS_CompileScript.

This still sounds like something odd is going on.  Why would that debug 
code affect execution?  The *printf calls may well disturb the malloc 
heap, which suggests an impurity somewhere, if my compiler bug hunch (or 
memory -- MIPS compilers from SGI had bugs in ages past) does not pan out.

What is the crash in JS_CompileScript?

The crash you originally reported, in js_CompareStrings -- what is the 
bad instruction and bad address?  What are the argument values and local 
variable values in these functions?

js_CompareStrings
js_compare_atom_keys
JS_HashTableRawLookup
js_AtomizeString
js_Atomize

/be

.