If you add a branch callback to js.c like the one in SMDev_BRANCH, you get a crash after the GC runs. Might be failing to root the script object or something? [shaver@zamboni src-40]$ Linux_All_DBG.OBJ/js js> for (i = 0; i < 4095; i++) { a = new String(); } js> for (i = 0; i < 4096; i++) { a = new String(); } :135065168: ^yntax error:callback] ?USegmentation fault (core dumped) (terminal control characters are causing some lossage, but you can see the effect) #0 0x80a7424 in GetChar (ts=0x80dc6d0) at jsscan.c:260 260 c = ts->ungetbuf[--ts->ungetpos]; (gdb) bt 5 #0 0x80a7424 in GetChar (ts=0x80dc6d0) at jsscan.c:260 #1 0x80a80b0 in js_GetToken (cx=0x80cc598, ts=0x80dc6d0) at jsscan.c:706 #2 0x8094e33 in js_Parse (cx=0x80cc598, chain=0x80cd9d0, ts=0x80dc6d0, cg=0xbffff8b8) at jsparse.c:218 #3 0x80492c5 in Process (cx=0x80cc598, obj=0x80cd9d0, filename=0x0) at js.c:192 #4 0x8049771 in ProcessArgs (cx=0x80cc598, obj=0x80cd9d0, argv=0xbffff998, argc=0) at js.c:339 This doesn't happen on SMDev_BRANCH.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

insure++ offers the following: [js.c:243] **READ_DANGLING** >> cg.firstLine = ts->lineno; Reading from a dangling pointer: ts Pointer : 0x083cfff0 In block: 0x083cffe0 thru 0x083d03f6 (1047 bytes) b, allocated at: JS_ArenaAllocate() jsarena.c, 107 js_NewBufferTokenStream() jsscan.c, 192 js_NewFileTokenStream() jsscan.c, 220 Process() js.c, 162 ProcessArgs() js.c, 339 main() js.c, 1674 stack trace where memory was freed: FreeArenaList() jsarena.c, 164 JS_FinishArenaPool() jsarena.c, 209 JS_GC() jsapi.c, 864 JS_MaybeGC() jsapi.c, 878 BranchCallback() js.c, 147 js_Interpret() jsinterp.c, 1165 Stack trace where the error occurred: Process() js.c, 243 ProcessArgs() js.c, 339 main() js.c, 1674 How is ts ending up in the tempPool arena? Well, that's where we allocate it! From js_NewFileTokenStream: ts = js_NewBufferTokenStream(cx, base, JS_LINE_LIMIT); From js_NewBufferTokenStream: JS_ARENA_ALLOCATE(ts, &cx->tempPool, nb); if (!ts) { JS_ReportOutOfMemory(cx); This looks like a real bug -- if there's any token stream active on a given context when it calls GC, we're in trouble. Can that happen without JSFILE, though?

This looks to me like a 'misuse' of the token stream. The function Process in the js.c shell reuses the token stream. In js_CompileTokenStream the token stream protects itself from having the gc run *while the compile is happening*. This ought to protect against recursive compilation like when an eval or Load happens. But in the interactive shell the use of tokenstream in Process assumes that it will stay around and be reusable later - that it will survive the JS_ExecuteScript and be there for the next call to js_CompileTokenStream. I'd say that this is either an error in Process, or a failure to have token streams protect themselves from gc while not actually doing the compile. Are token streams really supposed to be reusable? If so, then they need to protect themselves better. If not then this is not an engine bug, but a shell bug and Process should be fixed (and we should make sure token streams are not recycled in other code too). Which is it? I do think that this was uncovered not by changes in the engine, but because the shell loop has changed.

I'll accept this as assigned, but I'm lowering the priority, and I'll probably be sitting on it for a while.

cbegle, is this a Linux only bug, or occurs on all platforms?

did you like fix this? it's not crashing anymore. /h/omo/erectus/javascript14/builds/19990513_L.1/discostu_Linux2.0.35/mozilla/js / src/Linux_All_OPT.OBJ/ js> for (i = 0; i < 4095; i++) { a = new String(); } js> for (i = 0; i < 4096; i++) { a = new String(); } js>

I think jband's assessment is correct, and that it's a shell bug. mccabe might want to mark it WONTFIX on the branch, or FIXED on the tip/other branch.

Shaver, can you comment? It's been nagging for many milestones now, and it's still not clear that it's actually a problem.

I thought I did comment. I think it's a shell bug, and it's not critical that it be fixed on the branch -- the shell isn't a supported part of the engine. If you agree, mark it WONTFIX or FIXED depending on whether you think the branch status or tip status is more important.

Marking WONTFIX. I want it off the mozilla bug radar, and I suspect that it might be fixed anyway. (And any is on the SpiderMonkey140_BRANCH).

Javacsript component begin retired. Moving this bug to Javascript Engine.

Marking Verified/Won't Fix.