Bugzilla@Mozilla – Bug 528644
Crash [@ js_GetUpvar]
Last modified: 2010-09-27 20:06:33 PDT
Summon comment box
function g(foo) { for (a in foo) function() {} } (g((eval("\ function() {\ for each(b in [0]) {\ __defineGetter__(\"x\", \ function(b) \ eval(\"new function() { yield print(b) }\" ) \ )\ } \ return x\ }\ "))()))() crashes js debug and opt shell at js_GetUpvar near null on TM tip on 10.5.8. autoBisect shows this is probably related to bug 488034: The first bad revision is: changeset: 27186:70111870bcf8 user: Brendan Eich date: Mon Apr 13 14:16:15 2009 -0700 summary: Bug 488034 - Crash [@ js_GetUpvar] or "Assertion failure: (script)->upvarsOffset != 0, at ../jsinterp.cpp" (r=mrbkap). Debug stack: Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000018 Crashed Thread: 0 Thread 0 Crashed: 0 js-dbg-tm-darwin 0x00098a46 js_GetUpvar + 76 1 js-dbg-tm-darwin 0x0008d56c js_Interpret + 111234 2 js-dbg-tm-darwin 0x0009e9ab __ZL15SendToGeneratorP9JSContext13JSGeneratorOpP8JSObjectP11JSGeneratorl + 561 3 js-dbg-tm-darwin 0x0009ede8 __ZL12generator_opP9JSContext13JSGeneratorOpPlj + 610 4 js-dbg-tm-darwin 0x0009ee91 __ZL14generator_nextP9JSContextjPl + 39 5 js-dbg-tm-darwin 0x0009c1bb js_Invoke + 1503 6 js-dbg-tm-darwin 0x0009cbb3 js_InternalInvoke + 151 7 js-dbg-tm-darwin 0x0009fa60 js_CallIteratorNext + 360 8 js-dbg-tm-darwin 0x000773a2 js_Interpret + 20664 9 js-dbg-tm-darwin 0x0009b81b js_Execute + 1169 10 js-dbg-tm-darwin 0x000111ba JS_ExecuteScript + 54 11 js-dbg-tm-darwin 0x00009e5e __ZL7ProcessP9JSContextP8JSObjectPci + 458 12 js-dbg-tm-darwin 0x0000aba0 __ZL11ProcessArgsP9JSContextP8JSObjectPPci + 2272 13 js-dbg-tm-darwin 0x0000af6d main + 953 14 js-dbg-tm-darwin 0x00001d6b _start + 209 15 js-dbg-tm-darwin 0x00001c99 start + 41
(In reply to comment #0) > crashes js debug and opt shell at js_GetUpvar near null on TM tip on 10.5.8. ... and occurs without -j.
Nominating blocking1.9.1? since it got turned security-sensitive and affects 1.9.1 branch.
Is this a nearly-null memory read, not exploitable? /be
I have the cause of the crash. The crash is in trying to access |b| in |yield print(b)|. This is compiled as a JSOP_GETUPVAR in a function at static level 5 getting a variable |x| defined at static level 3 (|function (b) ...|). But the function at level 3 has returned by the time we re-enter the function that accesses |b|, so we crash. It seems that the generator function should not be compiled with JSOP_GETUPVAR at all, since it escapes. I'll have to dig in to the regressing patch and the closure compiler to figure out the exact cause and solution.
Created attachment 420408 [details] [review] Patch
http://hg.mozilla.org/tracemonkey/rev/a578f79c7dd2
http://hg.mozilla.org/mozilla-central/rev/a578f79c7dd2
This "ridealong" got left behind.
Comment on attachment 420408 [details] [review] Patch a=LegNeato for 1.9.2.6
Comment on attachment 420408 [details] [review] Patch Also approving for 1.9.1.11
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/65e8cc0b9c5c
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/dc2e2f77450e
gary: is there is a way to verify this fix in a debug build ?
Any update on this? Gary?
(In reply to comment #14) > Any update on this? Gary? I no longer crash using TM changeset 7cb520995757 on a 32-bit debug shell. Verified fixed. Also verified on 1.9.2 changeset df760e6d4ddc and 1.9.1 changeset 2eb0724d74f8