Closed Bug 350238 Opened 19 years ago Closed 18 years ago

<x/>.@*++ causes "Assertion failure: JS_UPTRDIFF(fp->sp, fp->spbase) <= depthdiff" at jsinterp.c:392

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: jruderman, Assigned: brendan)

References

Details

(4 keywords, Whiteboard: [sg:critical?])

Attachments

(2 files)

fix
2.58 KB, patch
mrbkap
: review+
dveditz
: approval1.8.0.8+
Details | Diff | Splinter Review
e4x/Regress/regress-350238.js
2.05 KB, text/plain
Details
Steps to reproduce: In a debug build, javascript:<x/>.@*++; Result: Assertion failure: JS_UPTRDIFF(fp->sp, fp->spbase) <= depthdiff, at jsinterp.c:392
WFM -- someone with time feel free to binary search and find the dup. /be
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
No, I'm on crack. /be
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Bug not fixed by patch for bug 316885.
Assignee: general → brendan
Blocks: js1.7
Group: security
Status: REOPENED → NEW
Flags: blocking1.8.1?
OS: Mac OS X 10.4 → All
Priority: -- → P1
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.8.1
Attached patch fix — — Splinter Review
The fix for bug 316885 was just not good enough. The maximum model stack depth is reached in the midst of code generation for the JOF_PROP and JOF_ELEM cases, so testing cg->stackDepth before or after the whole foo.bar++ (or equivalent) will not find a deep enough stack to seem to need adding one to cg->maxStackDepth. This patch simply bumps cg->stackDepth before code generation, and drops it after, for the post-increment, non-JOF_NAME cases. /be
Attachment #237038 - Flags: superreview?(shaver)
Attachment #237038 - Flags: review?(mrbkap)
Attachment #237038 - Flags: approval1.8.0.8?
Status: NEW → ASSIGNED
Attachment #237038 - Flags: review?(mrbkap) → review+
Flags: blocking1.8.0.8?
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
Whiteboard: [sg:critical?]
Comment on attachment 237038 [details] [diff] [review] fix Fixed on trunk. /be
Attachment #237038 - Flags: superreview?(shaver) → approval1.8.1?
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Flags: blocking1.8.1? → blocking1.8.1+
Fixed on the 1.8 branch. /be
Keywords: fixed1.8.1
verified fixed 1.9a1_2006090707 windows/mac*/linux note to self: need to deal with time out in browser due to use of document.location
Status: RESOLVED → VERIFIED
verified fixed 1.8 1.9 20060909 windows/mac*/linux
Keywords: fixed1.8.1 → verified1.8.1
Blocks: 352079
Blocks: 352272
Note bug 352272, whose patch should follow this bug's into any branches for which it gets approved. /be
Restoring lost blocking flag
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9? → blocking1.8.0.8?
Flags: blocking1.8.0.8? → blocking1.8.0.8-
Whiteboard: [sg:critical?] → [sg:critical?] js1.7 feature
This bug is in 1.8.0 branch code too. /be
Flags: blocking1.8.0.8- → blocking1.8.0.8?
Dveditz: this bug's testcase uses E4X, which was in 1.8/Firefox1.5. There is no js1.7 feature involved. /be
Whiteboard: [sg:critical?] js1.7 feature → [sg:critical?]
Flags: blocking1.8.0.8? → blocking1.8.0.8+
Comment on attachment 237038 [details] [diff] [review] fix approved for 1.8.0 branch, a=dveditz for drivers
Attachment #237038 - Flags: approval1.8.0.9? → approval1.8.0.8+
Fixed on the 1.8.0 branch: Checking in jsemit.c; /cvsroot/mozilla/js/src/jsemit.c,v <-- jsemit.c new revision: 3.128.2.3.2.10; previous revision: 3.128.2.3.2.9 done /be
Keywords: fixed1.8.0.8
verified 1.8.0.8 20061003 windows/mac*/linux
Keywords: fixed1.8.0.8 → verified1.8.0.8
Attachment #237038 - Flags: approval1.8.1?
Group: security
Checking in regress-350238.js; /cvsroot/mozilla/js/tests/e4x/Regress/regress-350238.js,v <-- regress-350238.js initial revision: 1.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: