Closed
Bug 350809
Opened 19 years ago
Closed 19 years ago
yield in xml-filtering-predicate causes assertion failure
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.8.1
People
(Reporter: jruderman, Assigned: brendan)
Details
(Keywords: crash, testcase, verified1.8.1, Whiteboard: [baking until 09/08])
Attachments
(2 files, 1 obsolete file)
|
2.50 KB,
patch
|
igor
:
review+
|
Details | Diff | Splinter Review |
|
2.52 KB,
patch
|
brendan
:
review+
mtschrep
:
approval1.8.1+
|
Details | Diff | Splinter Review |
javascript:(function(){ <x/>.(yield 4) })().next();
Assertion failure: fp->sp == sp, at /Users/admin/trunk/mozilla/js/src/jsinterp.c:5718
| Assignee | ||
Comment 1•19 years ago
|
||
If bug 309894 were fixed we could remove this error, but that bug won't be fixed in js1.7.
If this is considered too much for a hard case, I could make a runtime error when yield actually unwinds js_Interpret from called from JSOP_FILTER. Thoughts?
/be
| Assignee | ||
Comment 2•19 years ago
|
||
This catches the error only at runtime, which is less helpful and may be missed if code coverage is incomplete -- but the patch is smaller.
/be
Attachment #237082 -
Flags: review?(igor.bukanov)
| Assignee | ||
Updated•19 years ago
|
OS: Mac OS X 10.4 → All
Priority: -- → P1
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.8.1
Comment 3•19 years ago
|
||
Comment on attachment 237082 [details] [diff] [review]
altern-a-patch
>+MSG_DEF(JSMSG_YIELD_FROM_FILTER, 217, 0, JSEXN_TYPEERR, "yield disallowed from filtering predicate")
What about using more honest "yield from filtering predicate is not supported" with JSEXN_INTERNALERR?
Attachment #237082 -
Flags: review?(igor.bukanov) → review+
Comment 4•19 years ago
|
||
(In reply to comment #1)
> If this is considered too much for a hard case, I could make a runtime error
> when yield actually unwinds js_Interpret from called from JSOP_FILTER.
> Thoughts?
A runtime error emphases that this is a temporary interpreter implementation, not a permanent syntax error IMO.
| Assignee | ||
Updated•19 years ago
|
Attachment #237081 -
Attachment is obsolete: true
Attachment #237081 -
Flags: review?(igor.bukanov)
| Assignee | ||
Comment 5•19 years ago
|
||
I'm checking this in.
/be
Attachment #237132 -
Flags: review+
Attachment #237132 -
Flags: approval1.8.1?
| Assignee | ||
Comment 6•19 years ago
|
||
Fixed on trunk.
/be
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Whiteboard: [baking until 09/08]
| Assignee | ||
Comment 7•19 years ago
|
||
Not sure why this is baking, esp. compared to other fixes that aren't. This is adding a new error to a case that assertbotches debug builds and probably crashes release ones, and it can't be making things worse since the condition tested to throw the error instead of crashing is exactly the condition that leads to the crash.
/be
| Assignee | ||
Comment 8•19 years ago
|
||
This bug is quite comparable in scope and risk of its fix to bug 350279, whose patch was approved without extra baking.
/be
Comment 9•19 years ago
|
||
Comment on attachment 237132 [details] [diff] [review]
altern-a-patch to commit
a=schrep for drivers.
Attachment #237132 -
Flags: approval1.8.1? → approval1.8.1+
Comment 11•19 years ago
|
||
Checking in regress-350809.js;
/cvsroot/mozilla/js/tests/js1_7/geniter/regress-350809.js,v <-- regress-350809.js
initial revision: 1.1
Updated•19 years ago
|
Flags: in-testsuite+
Comment 12•19 years ago
|
||
verified fixed 1.8 1.9 20060909 windows/mac*/linux
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•