Last Comment Bug 542849 - (CVE-2010-0165) Assertion failure: targetObj == globalObj in TraceRecorder::traverseScopeChain
(CVE-2010-0165)
: Assertion failure: targetObj == globalObj in TraceRecorder::traverseScopeChain
Status: RESOLVED FIXED
[sg:critical]
: assertion, regression, verified1.9.2
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 1.9.2 Branch
: x86 All
: -- normal (vote)
: ---
Assigned To: David Mandelin [:dmandelin]
:
Mentors:
http://www.vanguardia.com.mx/
Depends on:
Blocks: 532972 523793
  Show dependency treegraph
 
Reported: 2010-01-28 12:56 PST by Bob Clary [:bc:]
Modified: 2010-03-24 00:25 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.2-fixed
unaffected


Attachments
Patch for 1.9.2 (1.70 KB, patch)
2010-02-19 13:42 PST, David Mandelin [:dmandelin]
dvander: review+
mbeltzner: approval1.9.2.2+
Details | Diff | Review

Description Bob Clary [:bc:] 2010-01-28 12:56:55 PST
1. http://www.vanguardia.com.mx/
2. Assertion failure: targetObj == globalObj, at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:12700

1.9.2 win/mac. couldn't reproduce on 1.9.3 mac. sensitive cause the assertion seems scary. saved version of the page didn't assert.

Program received signal SIGTRAP, Trace/breakpoint trap.
JS_Assert (s=0x44784e "targetObj == globalObj", file=0x4442c0 "/work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp", ln=12700) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsutil.cpp:69
69	    abort();
(gdb) bt
#0  JS_Assert (s=0x44784e "targetObj == globalObj", file=0x4442c0 "/work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp", ln=12700) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsutil.cpp:69
#1  0x003cf13d in TraceRecorder::traverseScopeChain (this=0x18165b00, obj=0x155578e0, obj_ins=0x10a2d60, targetObj=0x155576c0, targetIns=@0xbfffbbb4) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:12700
#2  0x003e0963 in TraceRecorder::callProp (this=0x18165b00, obj=0x155576c0, obj2=0x155576c0, prop=0x1ed03530, id=4547668, vp=@0xbfffbd18, ins=@0xbfffbd14, nr=@0xbfffbd00) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:7750
#3  0x003e111c in TraceRecorder::scopeChainProp (this=0x18165b00, obj=0x155576c0, vp=@0xbfffbd18, ins=@0xbfffbd14, nr=@0xbfffbd00) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:7691
#4  0x003e11ef in TraceRecorder::name (this=0x18165b00, vp=@0xbfffbd18, ins=@0xbfffbd14, nr=@0xbfffbd00) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:11972
#5  0x003e1724 in TraceRecorder::record_JSOP_NAME (this=0x18165b00) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:12275
#6  0x003e76bd in TraceRecorder::monitorRecording (cx=0x1e988000, tr=0x18165b00, op=JSOP_NAME) at jsopcode.tbl:180
#7  0x002f5528 in js_Interpret (cx=0x1e988000) at jsops.cpp:79
#8  0x00320cb0 in js_Invoke (cx=0x1e988000, argc=1, vp=0x1ea1a26c, flags=0) at jsinterp.cpp:1368
#9  0x002e5b24 in js_fun_apply (cx=0x1e988000, argc=1, vp=0x1ea1a234) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsfun.cpp:2046
#10 0x0030cde3 in js_Interpret (cx=0x1e988000) at jsops.cpp:2208
#11 0x0031f58b in js_Execute (cx=0x1e988000, chain=0x15099020, script=0x1eba5a00, down=0x0, flags=0, result=0x0) at jsinterp.cpp:1601
Comment 1 Bob Clary [:bc:] 2010-02-06 07:31:03 PST
Also http://noticias.terra.com.br/
Comment 2 David Mandelin [:dmandelin] 2010-02-09 14:20:50 PST
I've been bisecting this in spare moments, and I found the problem started here:

changeset:   33410:04ccc3cdaa53
user:        David Anderson <dvander@alliedmods.net>
date:        Sun Dec 20 15:02:56 2009 -0500
summary:     Fix tracer with certain scope chain layouts. 523793. r=mrbkap
Comment 3 Carsten Book [:Tomcat] 2010-02-14 05:34:18 PST
another site where this assertion can be seen is www.terra.cl
Comment 4 David Mandelin [:dmandelin] 2010-02-19 13:42:36 PST
Created attachment 427845 [details] [diff] [review]
Patch for 1.9.2

A function that calls eval indirectly isn't heavyweight. If that function calls eval to create a closure, and that closure refers to a variable in the function, then traverseScopeChain as it was didn't see the call object, because it only looks for call objects that belong to heavyweights.

In this case, I think we just want to abort, because it's rare, and it isn't obvious that the scope chain will always have the same length.
Comment 5 Brendan Eich [:brendan] 2010-02-19 13:50:03 PST
Indirect eval is global eval now (ES5). Was it in the 1.9.2 Gecko release? I thought so. Cc'ing mrbkap.

If so, no Call objects should be searched, ever. Aborting is fine but if we can stay on trace and do global eval, even better.

/be
Comment 6 David Mandelin [:dmandelin] 2010-02-19 14:12:43 PST
(In reply to comment #5)
> Indirect eval is global eval now (ES5). Was it in the 1.9.2 Gecko release? I
> thought so. Cc'ing mrbkap.

It seems not. I tried the shell test case in TM tip, and it does not crash, but says 'm is not defined', as I would expect with indirect eval.

> If so, no Call objects should be searched, ever. Aborting is fine but if we can
> stay on trace and do global eval, even better.

If I change the test to have a global variable 'm', then we do trace it on trunk. So it looks like we're good.
Comment 7 David Mandelin [:dmandelin] 2010-02-19 14:24:45 PST
Comment on attachment 427845 [details] [diff] [review]
Patch for 1.9.2

Requesting approval because of security sensitivity.
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2010-02-26 13:58:10 PST
Comment on attachment 427845 [details] [diff] [review]
Patch for 1.9.2

a1922=beltzner
Comment 9 David Mandelin [:dmandelin] 2010-03-01 14:27:04 PST
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/71de40148a40
Comment 10 Robert Sayre 2010-03-14 12:12:03 PDT
dmandelin, this is FIXED, right?
Comment 11 [On PTO until 6/29] 2010-03-15 17:32:29 PDT
I do not see this assert on 1.9.2 post-fix.

Note You need to log in before you can comment on or make changes to this bug.