Closed Bug 506018 Opened 15 years ago Closed 15 years ago

crash in js_GetClosureVar, regression from Trace JSOP_NAME for general closures

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: sayrer, Assigned: dmandelin)

References

Details

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #496240 +++ clicking around http://www.viceland.com/index_us.php (occasionally nsfw)
Assignee: general → dmandelin
Flags: blocking1.9.2+
0x0026daad js_GetClosureVar(JSContext*, JSObject*, unsigned int, unsigned int, unsigned int, double*) + 109 0x005ced07 0 + 6089991 0xbfffd858 0 + 3221215320 0x002815fe js_MonitorLoopEdge(JSContext*, unsigned int&) + 1342 0x001d9f37 js_Interpret + 45623 (jsinterp.cpp:3360) 0x001df3bb js_Execute + 427 (jsinterp.cpp:1644) 0x0018abfb JS_EvaluateUCScriptForPrincipals + 155 (jsapi.cpp:5156)
(gdb) call DumpJSStack() 0 anonymous() ["http://www.viceland.com/includes/shadowbox-build-3.0b/libraries/sizzle/sizzle.js":7] r = "matches" s = [object HTMLDivElement] e = [function] this = [object Window] 1 anonymous() ["http://www.viceland.com/includes/shadowbox-build-3.0b/libraries/sizzle/sizzle.js":7] g = undefined o = undefined h = undefined q = [function] m = [function] c = [function] a = [function] l = "PSEUDO" j = /:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/ f = [object Object] n = false d = [function] i = 0 p = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"][^'"]*['"]|[^[\]'"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])(\s*,\s*)?/g b = [function] this = [object Window] 2 <TOP LEVEL> ["http://www.viceland.com/includes/shadowbox-build-3.0b/libraries/sizzle/sizzle.js":7] this = [object Window]
OK. I just duplicated it. I had to do a new build to do so, so it might be something even more recent that interacted with closures.
I think I've fixed it. I still need to come up with a shell test case though.
Attached patch Patch (deleted) — Splinter Review
The bug occurs when both the using and defining functions of the upvar are heavyweight. It turns out that I was implicitly assuming that: scdist(fp->scopeChain at use, defining func) + 1 == scdist(callee at use, def func) where |scdist(a,b)| is the number of scope chain links from |a| to |b|. This assumption is valid only if the using function is not heavyweight. The assumption was a pure mistake. The patch computes the distance from callee at use to def at func in both places, so everything always matches.
Attachment #390370 - Flags: review?(gal)
Attachment #390370 - Flags: review?(gal) → review+
Comment on attachment 390370 [details] [diff] [review] Patch > for (uint32 i = 0; i < scopeIndex; ++i) { > call = OBJ_GET_PARENT(cx, call); > } Overbraced nit. >- JSObject* objd = origobj; >+ JSObject* objd = JSVAL_TO_OBJECT(cx->fp->argv[-2]); Total nit again: canonical name for other such scope- and proto-chain index computations is tmp. /be
Priority: -- → P1
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(I fixed brendan's nits)
Mass change: adding fixed1.9.2 keyword (This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)
Keywords: fixed1.9.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: