Subj : Re: Crash during compilation
To   : Oscar
From : Brendan Eich
Date : Thu Aug 19 2004 02:54 pm

Oscar wrote:
> **** Post for FREE via your newsreader at post.usenet.com ****
> 
> Compile crash
> 
> Hi all, Brendan especially
> 
> I mange to get SM to crash when compiling a rather simple script.
> 
> The crash occurs in
> 
>     js_map_atom    [jsatom.c:781]
> 
> The problem seems to be that an atom, added to the cg->atomList->table by
> js_IndexAtom() during CompileTokenStream is freed in js_FinishCodeGenerator
> by the the row: JS_ARENA_RELEASE(&cx->tempPool, cg->tempMark,
> cx->runtime->modId);


Atoms are malloc'd, you must mean a JSAtomListElement allocated from 
cx->tempPool.


> A strange thing is that the js_FinishCodeGenerator which frees the atom is
> invoked by jsEmitTree right after js_EmitFunctionBody whereas the atom is
> added to to the atom list during CompileTokenStream.


That is strange -- arena-pool allocation is LIFO, so there shouldn't be 
any way for an older allocation, below the mark stored in cg2mark early 
in the TOK_FUNCTION case of js_EmitTree, to be freed by a newer release.


> As I understand it that would mean that the atom allocated and added during
> compilation of the "outline" script is removed when clearing the
> CodeGeneration for a nested function within the script.
> 
> Details of the problem are added below.
> 
> Does this problem description ring a bell ? Has it possibly been fixed? I
> have looked through the release notes and found nothing, however I'm not
> really sure what to look for anyway I'm afraid.
> 
> Is there any documentation of the SM code that can be made available? The
> readme.html is not quite enough.
> 
> I have very little understanding of what the cx->tempPool is and I therefore
> feel that it is hard to go forward.


See the comments and paper cited in the first non-license comment in 
jsarena.c.


> I am using SM 1.5 RC 5 (JavaScript-C 1.5 pre-release 5 2003-01-10)
> 
> Compiling using VC 6
> 
> I attach 3 call stacks:
> 
> The Error location
> 
>     js_map_atom    [jsatom.c:781]
>     JS_HashTableEnumerateEntries [jshash.c:369]
>     js_InitAtomMap [jsatom.c:821]
>     js_NewScriptFromCG [jsscript.c:807]
>     CompileTokenStream [jsapi.c:2724]
>     JS_CompileUCScriptForPrincipals [jsapi.c:2801]


Ok, this is indeed mapping a JSAtomListElement, which is allocated on 
cx->tempPool -- not a JSAtom.


> 
> 
> The allocation location
> 
>     JS_ArenaAllocate [jsarena.c:179]
>     AddJumpTarget  [jsemit.c:390]
>     SetSpanDepTarget [jsemit.c:452]
>     js_SetJumpOffset [jsemit.c:1175]
>     js_EmitTree    [jsemit.c:3528]
>     js_EmitTree    [jsemit.c:3477]
>     js_EmitTree    [jsemit.c:3323]
>     Statements     [jsparse.c:919]
>     js_CompileTokenStream [jsparse.c:396]
>     CompileTokenStream [jsapi.c:2719]
>     JS_CompileUCScriptForPrincipals [jsapi.c:2801]


Sure enough, that's for the outer ("outline"?) script.


> 
> 
> The Free location
> 
>     FreeArenaList  [jsarena.c:316]
>     JS_ArenaRelease [jsarena.c:344]
>     js_FinishCodeGenerator [jsemit.c:97]
>     js_EmitTree    [jsemit.c:2009]
>     Statements     [jsparse.c:919]
>     js_CompileTokenStream [jsparse.c:396]
>     CompileTokenStream [jsapi.c:2719]
>     JS_CompileUCScriptForPrincipals [jsapi.c:2801]


Sure enough, that's the release for the inner function's code generator 
finalization.

How could the inner cg have a mark "below" (conceptually; older, in 
allocation time order, per the LIFO rules for arena pools) the outer 
script's atom list element?


> The script i am trying to compile  looks like this:
> 
> function d(){
>   while(a.b(a.b-1) ==' ')
>  {
>     a.b.b=a.b.c.d(0,a.b.a - 1);
>   }
>   if (a.b.c != "") {
>    return true;
>   }
>   else {
>  }
> }
> var is= new Object();
> is.sac = (a.b.c().d("")> 0) ? 1 : 0;
> is.mac = (a.b.c().d("")> 0) ? 1 : 0;
> function t(){
>   if (a.b==c.d)
>    g();
> }
> 
> The problem is extremely sensitive, one must not change anything in the
> script or else the problem will disappear or manifest itself in some other
> way e.g. as an assert triggerd during interpretation


I can't reproduce the problem, and in fact the above source produces 
this error:

js> is.mac = (a.b.c().d("")> 0) ? 1 : 0;
14: ReferenceError: a is not defined

when pasted into the JS shell, current trunk revision.  Is that what you 
see?  I'll pull JS_150_RC5 and test there.

/be

.