Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) Reporter
	Description • 15 years ago

(function() {
  var a
  eval("for(b in[0,0,0,0]){}[a=0]")
})()

crashes js opt shell with -j on TM tip at js_CheckRedeclaration at null and asserts js debug shell with -j on TM tip at Assertion failure: !JSVAL_IS_PRIMITIVE(lval), at ../jsops.cpp:3521

autoBisect shows this is probably related to bug 495331:

The first bad revision is:
changeset:   37046:910ee7db07de
user:        David Mandelin
date:        Fri Jan 15 11:32:14 2010 -0800
summary:     Bug 495331: trace JSOP_LAMBDA for non-heavyweight, non-null closures, r=jorendorff,dvander

js opt shell stack:

===

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   js-opt-32-tm-darwin           	0x0005ddb2 js_CheckRedeclaration + 18
1   js-opt-32-tm-darwin           	0x00051cfd js_Interpret + 13149
2   js-opt-32-tm-darwin           	0x0005e65c js_Execute + 444
3   js-opt-32-tm-darwin           	0x00072a31 obj_eval(JSContext*, JSObject*, unsigned int, long*, long*) + 2369
4   js-opt-32-tm-darwin           	0x0005edb5 js_Invoke + 1093
5   js-opt-32-tm-darwin           	0x00054b7d js_Interpret + 25053
6   js-opt-32-tm-darwin           	0x0005e65c js_Execute + 444
7   js-opt-32-tm-darwin           	0x0000d91c JS_ExecuteScript + 60
8   js-opt-32-tm-darwin           	0x000047c5 Process(JSContext*, JSObject*, char*, int) + 1621
9   js-opt-32-tm-darwin           	0x00008726 main + 1734
10  js-opt-32-tm-darwin           	0x0000264d _start + 208
11  js-opt-32-tm-darwin           	0x0000257c start + 40

	David Mandelin [:dmandelin] Assignee
	Comment 4 • 15 years ago

The cause: we were setting |scopeChain->private| to incorrect values when leaving trace. Because generally heavyweight functions get their own Call object, which should point back to their active frame, I wrote the original patch to set the private when leaving trace if |fp->fun-flags & JSFUN_HEAVYWEIGHT|. But it appears that |eval| makes a frame that is considered heavyweight, but shares the Call object with its caller. So in that case, it is wrong to make the Call private point to the current frame (it should point to the down frame, as it does when created).

To fix, I made it reset the scopeChain private only if the scopeChain private is currently NULL. In general, there are two ways that can happen:

  1. The Call object was created on trace and we are still on trace or have not
    yet finished building the interpreter frames.

  2. The frame for that Call object has returned.

If we are looking at a frame object and JSFUN_HEAVYWEIGHT is set in frame->fun->flags when leaving trace, there are two possibilities:

  a. The frame is the trace entry frame. In this case, we should not set
     scopeChain->private, because the interpreter already did when we 
     entered the frame. This also means the private is not null.

  b. The frame is not the trace entry frame. In this case, we should set
     scopeChain->private, and it is currently null.

Thus, it is correct to set the scopeChain private iff the scopeChain private is currently NULL.

	David Mandelin [:dmandelin] Assignee
	Comment 7 • 15 years ago

http://hg.mozilla.org/tracemonkey/rev/7afd318ba3c6

	Robert Sayre
	Comment 8 • 15 years ago

http://hg.mozilla.org/mozilla-central/rev/7afd318ba3c6

	Christian Holler (:decoder)
	Comment 9 • 12 years ago

A testcase for this bug was automatically identified at js/src/jit-test/tests/closures/bug540528.js.