Found with a 2006070122 winxp trunk build. If it doesn't crash immediately, reload a couple of times. Marking sensitive since it uses deleted memory. + script 0x03cbd708 {code=0xdddddddd <Bad Ptr> length=3722304989 main=0xdddddddd <Bad Ptr> ...} JSScript * => SCRIPT_FIND_CATCH_START(script, pc, pc); > js3250.dll!js_Interpret(JSContext * cx=0x039245d0, unsigned char * pc=0x03cbd779, long * result=0x0012f82c) Line 6140 + 0x42 bytes C js3250.dll!generator_send(JSContext * cx=0x039245d0, JSObject * obj=0x045d9888, unsigned int argc=0, long * argv=0x03a97460, long * rval=0x0012f910) Line 784 + 0x14 bytes C js3250.dll!generator_close(JSContext * cx=0x039245d0, JSObject * obj=0x045d9888, unsigned int argc=0, long * argv=0x03a97460, long * rval=0x0012f910) Line 834 + 0x17 bytes C js3250.dll!js_Invoke(JSContext * cx=0x039245d0, unsigned int argc=0, unsigned int flags=2) Line 1328 + 0x20 bytes C js3250.dll!js_InternalInvoke(JSContext * cx=0x039245d0, JSObject * obj=0x045d9888, long fval=73242784, unsigned int flags=0, unsigned int argc=0, long * argv=0x00000000, long * rval=0x0012fa64) Line 1422 + 0x14 bytes C js3250.dll!generator_closehook(JSContext * cx=0x039245d0, JSObject * obj=0x045d9888) Line 638 + 0x1b bytes C js3250.dll!ExecuteCloseHooks(JSContext * cx=0x039245d0, const JSObjectsToClose * toClose=0x0012fb10) Line 1017 + 0x10 bytes C js3250.dll!js_GC(JSContext * cx=0x039245d0, unsigned int gcflags=0) Line 2771 + 0xd bytes C js3250.dll!js_ForceGC(JSContext * cx=0x039245d0, unsigned int gcflags=0) Line 2234 + 0xd bytes C js3250.dll!JS_GC(JSContext * cx=0x039245d0) Line 1917 + 0xb bytes C gklayout.dll!nsJSContext::Notify(nsITimer * timer=0x04678ab0) Line 2996 + 0xd bytes C++ xpcom_core.dll!nsTimerImpl::Fire() Line 387 C++ xpcom_core.dll!nsTimerEvent::Run() Line 458 C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fc34) Line 483 C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00b382d8, int mayWait=1) Line 225 + 0x16 bytes C++ gkwidget.dll!nsBaseAppShell::Run() Line 153 + 0xc bytes C++ tkitcmps.dll!nsAppStartup::Run() Line 171 + 0x1c bytes C++

Same crash occurs with js1_7/geniter/pi-generator.js and js1_7/geniter/simple-fib.js as well.

I still get this nasty crash with deleted memory on the trunk during shutdown in the browser test using the v3 js17 rollup patch.

This occurs on 1.8.1a3/winxp as well now that js17 has landed. Note that deleted memory use is exploitable.

Is it possible to check this with the patch from bug 341821 applied?

r=mrbkap, who pointed out the hole. Newborn generators need to mark their frames in case nothing else keeps the frame's function alive. E.g. after clearing window scope and running close hooks (close hook execution needs work, but that's not this bug). /be

Fixed on trunk. /be

i am not sure this is fixed (though vanilla firefox doesn't crash). or it may be another bug. from: http://test.bclary.com/tests/mozilla.org/js/menu.html#SUITE_js1_7 select: fibonacci-matrix-generator.js iterator-toString.js and run the tests 2 times. when free/deleted memory is overwritten via hooks i crash with this: #4 0xb7f9a8cc in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:210 #5 <signal handler called> #6 0xb7e7b1a9 in js_Interpret (cx=0x8c3a200, pc=0x9016e71 'Ð' <repeats 200 times>..., result=0xbfffdf80) at /opt/joro/firefox/mozilla/js/src/jsinterp.c:6269 #7 0xb7e7dd16 in generator_send (cx=0x8c3a200, obj=0x9023630, argc=0, argv=0x9008020, rval=0xbfffe0d0) at /opt/joro/firefox/mozilla/js/src/jsiter.c:788 #8 0xb7e7de71 in generator_close (cx=0x8c3a200, obj=0x9023630, argc=0, argv=0x9008020, rval=0xbfffe0d0) at /opt/joro/firefox/mozilla/js/src/jsiter.c:838 #9 0xb7e5927b in js_Invoke (cx=0x8c3a200, argc=0, flags=2) at /opt/joro/firefox/mozilla/js/src/jsinterp.c:1349 #10 0xb7e596a8 in js_InternalInvoke (cx=0x8c3a200, obj=0x9023630, fval=151139912, flags=0, argc=0, argv=0x0, rval=0xbfffe244) at /opt/joro/firefox/mozilla/js/src/jsinterp.c:1447 #11 0xb7e7d7ee in generator_closehook (cx=0x8c3a200, obj=0x9023630) at /opt/joro/firefox/mozilla/js/src/jsiter.c:642 (gdb) frame 6 #6 0xb7e7b1a9 in js_Interpret (cx=0x8c3a200, pc=0x9016e71 'Ð' <repeats 200 times>..., result=0xbfffdf80) at /opt/joro/firefox/mozilla/js/src/jsinterp.c:6269 6269 SCRIPT_FIND_CATCH_START(script, pc, pc); Current language: auto; currently c (gdb) x/i $eip 0xb7e7b1a9 <js_Interpret+131421>: mov (%eax),%edx (gdb) p/x $eax $1 = 0xd0d0d0d0 and valgrind reports: ==24021== ==24021== Invalid read of size 4 ==24021== at 0x1BA3D09A: js_Interpret (jsinterp.c:2081) ==24021== by 0x1BA5FD15: generator_send (jsiter.c:788) ==24021== by 0x1BA5FE70: generator_close (jsiter.c:838) ==24021== by 0x1BA3B27A: js_Invoke (jsinterp.c:1349) ==24021== by 0x1BA3B6A7: js_InternalInvoke (jsinterp.c:1447) ==24021== by 0x1BA5F7ED: generator_closehook (jsiter.c:642) ==24021== by 0x1BA34E86: ExecuteCloseHooks (jsgc.c:1017) ==24021== by 0x1BA37E8D: js_GC (jsgc.c:2788) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== Address 0x23762D3C is 4 bytes inside a block of size 258 free'd ==24021== at 0x1B9003B3: free (vg_replace_malloc.c:235) ==24021== by 0x1B9F85C4: JS_free (jsapi.c:1672) ==24021== by 0x1BAA3D21: js_DestroyScript (jsscript.c:1371) ==24021== by 0x1BA2FE3F: fun_finalize (jsfun.c:1154) ==24021== by 0x1BA6D783: js_FinalizeObject (jsobj.c:2513) ==24021== by 0x1BA37C04: js_GC (jsgc.c:2685) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== by 0x1BB9D1C0: nsTimerEvent::Run() (nsTimerImpl.cpp:456) ==24021== by 0x1BB965B4: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:482) ==24021== ==24021== Invalid read of size 2 ==24021== at 0x1BA3D0CF: js_Interpret (jsinterp.c:2095) ==24021== by 0x1BA5FD15: generator_send (jsiter.c:788) ==24021== by 0x1BA5FE70: generator_close (jsiter.c:838) ==24021== by 0x1BA3B27A: js_Invoke (jsinterp.c:1349) ==24021== by 0x1BA3B6A7: js_InternalInvoke (jsinterp.c:1447) ==24021== by 0x1BA5F7ED: generator_closehook (jsiter.c:642) ==24021== by 0x1BA34E86: ExecuteCloseHooks (jsgc.c:1017) ==24021== by 0x1BA37E8D: js_GC (jsgc.c:2788) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== Address 0x23762D44 is 12 bytes inside a block of size 258 free'd ==24021== at 0x1B9003B3: free (vg_replace_malloc.c:235) ==24021== by 0x1B9F85C4: JS_free (jsapi.c:1672) ==24021== by 0x1BAA3D21: js_DestroyScript (jsscript.c:1371) ==24021== by 0x1BA2FE3F: fun_finalize (jsfun.c:1154) ==24021== by 0x1BA6D783: js_FinalizeObject (jsobj.c:2513) ==24021== by 0x1BA37C04: js_GC (jsgc.c:2685) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== by 0x1BB9D1C0: nsTimerEvent::Run() (nsTimerImpl.cpp:456) ==24021== by 0x1BB965B4: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:482) ==24021== ==24021== Invalid read of size 4 ==24021== at 0x1BA3D1CF: js_Interpret (jsinterp.c:2156) ==24021== by 0x1BA5FD15: generator_send (jsiter.c:788) ==24021== by 0x1BA5FE70: generator_close (jsiter.c:838) ==24021== by 0x1BA3B27A: js_Invoke (jsinterp.c:1349) ==24021== by 0x1BA3B6A7: js_InternalInvoke (jsinterp.c:1447) ==24021== by 0x1BA5F7ED: generator_closehook (jsiter.c:642) ==24021== by 0x1BA34E86: ExecuteCloseHooks (jsgc.c:1017) ==24021== by 0x1BA37E8D: js_GC (jsgc.c:2788) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== Address 0x23762D58 is 32 bytes inside a block of size 258 free'd ==24021== at 0x1B9003B3: free (vg_replace_malloc.c:235) ==24021== by 0x1B9F85C4: JS_free (jsapi.c:1672) ==24021== by 0x1BAA3D21: js_DestroyScript (jsscript.c:1371) ==24021== by 0x1BA2FE3F: fun_finalize (jsfun.c:1154) ==24021== by 0x1BA6D783: js_FinalizeObject (jsobj.c:2513) ==24021== by 0x1BA37C04: js_GC (jsgc.c:2685) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== by 0x1BB9D1C0: nsTimerEvent::Run() (nsTimerImpl.cpp:456) ==24021== by 0x1BB965B4: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:482) ==24021== ==24021== Invalid read of size 4 ==24021== at 0x1BA5D170: js_Interpret (jsinterp.c:6269) ==24021== by 0x1BA5FD15: generator_send (jsiter.c:788) ==24021== by 0x1BA5FE70: generator_close (jsiter.c:838) ==24021== by 0x1BA3B27A: js_Invoke (jsinterp.c:1349) ==24021== by 0x1BA3B6A7: js_InternalInvoke (jsinterp.c:1447) ==24021== by 0x1BA5F7ED: generator_closehook (jsiter.c:642) ==24021== by 0x1BA34E86: ExecuteCloseHooks (jsgc.c:1017) ==24021== by 0x1BA37E8D: js_GC (jsgc.c:2788) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917) ==24021== by 0x1ED2C9EE: nsJSContext::Notify(nsITimer*) (nsJSEnvironment.cpp:3072) ==24021== by 0x1BB9D02E: nsTimerImpl::Fire() (nsTimerImpl.cpp:386) ==24021== Address 0x23762D5C is 36 bytes inside a block of size 258 free'd ==24021== at 0x1B9003B3: free (vg_replace_malloc.c:235) ==24021== by 0x1B9F85C4: JS_free (jsapi.c:1672) ==24021== by 0x1BAA3D21: js_DestroyScript (jsscript.c:1371) ==24021== by 0x1BA2FE3F: fun_finalize (jsfun.c:1154) ==24021== by 0x1BA6D783: js_FinalizeObject (jsobj.c:2513) ==24021== by 0x1BA37C04: js_GC (jsgc.c:2685) ==24021== by 0x1BA36AB2: js_ForceGC (jsgc.c:2251) ==24021== by 0x1B9F8BED: JS_GC (jsapi.c:1917)

Comment on attachment 230064 [details] [diff] [review] fix a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and mark fixed1.8.1 once you have.

Should have seen this: js_NewGenerator does not copy argv[-2] or argv[-1]. My mistake, sorry. /be

Comment on attachment 230189 [details] [diff] [review] rest of the fix Dbaron, can you stamp this as if it was part of the "fix" patch :-/? /be

Georgi, thanks to you too -- shout if you see anything bad after the second patch goes in. /be

Fixed on trunk and (both patches landed at once) 1.8 branch. /be

pulled cvs and built trunk debug depends and still crash with same stack after clicking url bar and reloading. Same stacks now in bug 343295, bug 342793 and here.

Comment #7 still crashes for me with a linux trunk build from about half an hour ago. run with clearing hooks, same stack.

*** Bug 343295 has been marked as a duplicate of this bug. ***

The remaining problem is that js_MarkStackFrame does not mark fp->argv[-2]. /be

The frame marking code, even before it was factored out of js_GC into js_MarkStackFrame for use by generator_mark, always marked only fp->argv[0] through fp->argv[fp->argc-1]. For any non-initial frame, this marking should be redundant, because actual arguments (including callee at argv[-2] and this param at argv[-1]) come from the caller's operand stack, which is always marked as part of the process of marking the caller's frame. The redundant marking of only argv[0..(argc-1)] is historical, a latent bug that generator_mark has depended on -- but of course argv[-2] is left out. It turns out that fp->argv[-1] aliases fp->thisp, so needs no special marking. This can be asserted. The important thing to fix is to mark fp->argv[-2] from generator_mark, or from js_MarkStackFrame if we can prove it won't be marked when the caller's frame's operand stack space is marked. With Graydon's cycle collector and the rt->gcThingCallback it adds (bug 333078), it's important that GC-things not be marked redundantly. The cycle collector runs only from the idle loop, so it's not going to find operand stack and argv elements redundantly marking the same things, but we really should save cycles and avoid any future bugs to-do with redundant marking leading to overlarge reference counts computed by gcThingCallback. Patch shortly. /be

(In reply to comment #18) > With Graydon's cycle collector and the rt->gcThingCallback it adds (bug > 333078), it's important that GC-things not be marked redundantly. Of course I should have written "... it's important that GC-thing references not be marked redundantly." A jsval on the operand stack is a reference to a thing in the GC-heap, if JSVAL_IS_GCTHING(v). Such a reference should not be marked both by the caller frame's operand stack marking, and by the (prior, since the frame chain links downward) callee frame's argv marking, or rt->gcThingCallback will overcount one ref as two. /be

*** Bug 342793 has been marked as a duplicate of this bug. ***

(In reply to comment #19) > A jsval on the operand stack is a reference to a > thing in the GC-heap, if JSVAL_IS_GCTHING(v). Such a reference should not be > marked both by the caller frame's operand stack marking, and by the (prior, > since the frame chain links downward) callee frame's argv marking, or > rt->gcThingCallback will overcount one ref as two. This is hard to fix. If only generator frames needed to mark their own arguments (including argv[-2]), we could avoid marking argv (and thisp) in js_MarkStackFrame and count on js_MarkStackFrame called on the caller frame, or else generator_mark, doing the deed. Except: operand stack space that does not have enough room for missing formal parameters *and* local GC roots (JSFunctionSpec.extra) may require copying of actual parameters to new stack space that has enough room after the actuals for contiguous missing default-undefined and local GC-root slots. In such a hard case where the arguments "move", the original operand stack space will be marked, and the new space containing all the args, actual, formal, and local GC-root argv elements, will be marked. Given this complexity, I'm not going to attempt to minimize marking argv and operand stack refs to the same actual argument values. Instead, I'll just patch generator_mark to mark argv[-2]. /be

Extensive comments in the patch tell the story. /be

Fixed on trunk. /be

don't crash anymore. is this patch believed to be memory leak safe?

*** Bug 344921 has been marked as a duplicate of this bug. ***

(In reply to comment #24) > don't crash anymore. > > is this patch believed to be memory leak safe? Missing mark means dangling pointer -- fixing that doesn't leak since GC is a graph marking alg, not ref-counting. Only stuck roots or ref-counts can make a JS object leak. /be

Comment on attachment 230280 [details] [diff] [review] final fix (I hope) a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH.

Final patch landed on the 1.8 branch, along with GC_MARK_DEBUG improvements from bug 343417. /be

It's possible this caused a leak increase (bug 345530).

verified fixed trunk 20060723 win/linux/mac(ppc|tel)

Note: test: js1_7/geniter/fibonacci-matrix-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-01-31-12-firefox-2.0-opt-1.8.1b1_2006072314-linux5.log CRASHED signal 11 (2.156329 seconds) test: js1_7/geniter/fibonacci-matrix-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-05-43-40-firefox-2.0-dbg-1.8.1b1_2006072312-prune.log CRASHED 5 (2.453000 seconds) test: js1_7/geniter/fibonacci-matrix-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-08-35-59-firefox-2.0-dbg-mac-1.8.1b1_2006072312-pineapple.mozilla.org.log CRASHED signal 6 (4.965330 seconds) and bug 343295 Comment 7, bug 342793 Comment 7

test: js1_7/geniter/pi-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-05-43-40-firefox-2.0-dbg-1.8.1b1_2006072312-prune.log CRASHED 5 (2.437000 seconds) test: js1_7/geniter/pi-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-08-35-59-firefox-2.0-dbg-mac-1.8.1b1_2006072312-pineapple.mozilla.org.log CRASHED signal 6 (4.230876 seconds) test: js1_7/geniter/pi-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-10-20-11-firefox-2.0-dbg-mac-1.8.1b1_2006072313-lb-qamini01.office.mozilla.org.log CRASHED signal 5 (8.275441 seconds) test: js1_7/geniter/pi-generator.js: result: CRASHED type: browser description: none : results/2006-07-24-10-22-53-firefox-2.0-dbg-mac-1.8.1b1_2006072313-lb-qamini02.office.mozilla.org.log CRASHED signal 5 (8.335850 seconds)

test: js1_7/geniter/simple-fib.js: result: CRASHED type: browser description: none : results/2006-07-24-05-43-40-firefox-2.0-dbg-1.8.1b1_2006072312-prune.log CRASHED 5 (2.421000 seconds) test: js1_7/geniter/simple-fib.js: result: CRASHED type: browser description: none : results/2006-07-24-08-35-59-firefox-2.0-dbg-mac-1.8.1b1_2006072312-pineapple.mozilla.org.log CRASHED signal 6 (4.237336 seconds) test: js1_7/geniter/simple-fib.js: result: CRASHED type: browser description: none : results/2006-07-24-08-37-17-firefox-2.0-dbg-mac-1.8.1b1_2006072312-papaya.mozilla.org.log CRASHED signal 6 (4.636812 seconds) test: js1_7/geniter/simple-fib.js: result: CRASHED type: browser description: none : results/2006-07-24-10-20-11-firefox-2.0-dbg-mac-1.8.1b1_2006072313-lb-qamini01.office.mozilla.org.log CRASHED signal 5 (8.133016 seconds) test: js1_7/geniter/simple-fib.js: result: CRASHED type: browser description: none : results/2006-07-24-10-22-53-firefox-2.0-dbg-mac-1.8.1b1_2006072313-lb-qamini02.office.mozilla.org.log CRASHED signal 5 (8.230659 seconds) t

I'm confused ... what's crashing?

(In reply to comment #34) > I'm confused ... what's crashing? > js1_7/geniter/fibonacci-matrix-generator.js js1_7/geniter/pi-generator.js js1_7/geniter/simple-fib.js

(In reply to comment #35) > (In reply to comment #34) > > I'm confused ... what's crashing? > > > > js1_7/geniter/fibonacci-matrix-generator.js > js1_7/geniter/pi-generator.js > js1_7/geniter/simple-fib.js > don' crash on linux trunk with clearing hooks on the above. but get this assertion: WARNING: Moving XPConnect wrappedNative to new scope, but can't fixup __proto__: file /opt/joro/firefox/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 1101

on linux trunk bclary's js1_7 pass under valgrind without valgrind whining for memory screw (or the screw warning is suppressed)

don't crash on macosx ppc trunk

(In reply to comment #35) > (In reply to comment #34) > js1_7/geniter/fibonacci-matrix-generator.js > js1_7/geniter/pi-generator.js > js1_7/geniter/simple-fib.js passes 1.8/1.9 2006072500 verified fixed windows/mac(ppc|tel)/linux.

crash browser 1.9 debug 20060811 on js1_7/GC/regress-341675.js at ntdll.dll!_RtlEnterCriticalSection@4() + 0x90 bytes ntdll.dll!_RtlEnterCriticalSection@4() + 0x90 bytes > msvcr80d.dll!_lock_file(_iobuf * pf=0x00240000) Line 238 C msvcr80d.dll!fprintf(_iobuf * str=0x00240000, const char * format=0x00553bf8, ...) Line 63 + 0x9 bytes C js3250.dll!js_Interpret(JSContext * cx=0x0437db20, unsigned char * pc=0x04690d40, long * result=0x0012e80c) Line 6171 + 0x1f bytes C js3250.dll!generator_send(JSContext * cx=0x0437db20, JSObject * obj=0x0462b990, unsigned int argc=0, long * argv=0x04555118, long * rval=0x0012e8f8) Line 795 + 0x14 bytes C js3250.dll!generator_close(JSContext * cx=0x0437db20, JSObject * obj=0x0462b990, unsigned int argc=0, long * argv=0x04555118, long * rval=0x0012e8f8) Line 846 + 0x17 bytes C js3250.dll!js_Invoke(JSContext * cx=0x0437db20, unsigned int argc=0, unsigned int flags=2) Line 1350 + 0x20 bytes C js3250.dll!js_InternalInvoke(JSContext * cx=0x0437db20, JSObject * obj=0x0462b990, long fval=73578920, unsigned int flags=0, unsigned int argc=0, long * argv=0x00000000, long * rval=0x0012ea4c) Line 1448 + 0x14 bytes C js3250.dll!js_CloseGeneratorObject(JSContext * cx=0x0437db20, JSGenerator * gen=0x046ae030) Line 623 + 0x1b bytes C js3250.dll!js_RunCloseHooks(JSContext * cx=0x0437db20) Line 1057 + 0xd bytes C js3250.dll!JS_GC(JSContext * cx=0x0437db20) Line 1943 + 0x9 bytes C js3250.dll!JS_MaybeGC(JSContext * cx=0x0437db20) Line 2009 + 0x9 bytes C gklayout.dll!nsJSContext::DOMBranchCallback(JSContext * cx=0x0437db20, JSScript * script=0x04690850) Line 688 + 0xa bytes C++ js3250.dll!js_Interpret(JSContext * cx=0x0437db20, unsigned char * pc=0x04690914, long * result=0x0012f718) Line 2434 + 0x66 bytes C js3250.dll!js_Execute(JSContext * cx=0x0437db20, JSObject * chain=0x04605478, JSScript * script=0x04680a50, JSStackFrame * down=0x00000000, unsigned int flags=0, long * result=0x0012f844) Line 1599 + 0x13 bytes C js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x0437db20, JSObject * obj=0x04605478, JSPrincipals * principals=0x038e39e4, const unsigned short * chars=0x046a1d60, unsigned int length=2295, const char * filename=0x046761c0, unsigned int lineno=1, long * rval=0x0012f844) Line 4363 + 0x19 bytes C gklayout.dll!nsJSContext::EvaluateString(const nsAString_internal & aScript={...}, void * aScopeObject=0x04605478, nsIPrincipal * aPrincipal=0x038e39e0, const char * aURL=0x046761c0, unsigned int aLineNo=1, unsigned int aVersion=170, nsAString_internal * aRetValue=0x00000000, int * aIsUndefined=0x0012f92c) Line 1298 + 0x43 bytes C++ gklayout.dll!nsScriptLoader::EvaluateScript(nsScriptLoadRequest * aRequest=0x0466c688, const nsString & aScript={...}) Line 800 + 0x63 bytes C++ see bug 341815 Comment #15

filed Bug 348606 on the _RtlEnterCriticalSection debug browser crash

Since this says it's a regression from the js1.7 landing I assume it doesn't apply to 1.8.0.x, but I haven't tried the testcase. bc? Please renominate if we've gotten that wrong.