The default bug view has changed. See this FAQ.

E4X - JS_ASSERT @ js_Interpret, line 5070

RESOLVED FIXED in mozilla1.8beta5

Status

()

Core
JavaScript Engine
P1
normal
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: bc, Assigned: brendan)

Tracking

({fixed1.8, js1.6, regression})

Trunk
mozilla1.8beta5
fixed1.8, js1.6, regression
Points:
---
Bug Flags:
blocking1.8b5 +
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
This assert began appearing recently in debug builds in
e4x/Regress/regress-301596.js. Related to bug 309850 ?

+	fp->sp	0x0041d9ec
+	sp	0x0041d9f0

NTDLL! 7c901230()
js_Interpret(JSContext * 0x000371b8, unsigned char * 0x00424a84, long *
0x0013ee24) line 5070 + 36 bytes
js_Execute(JSContext * 0x000371b8, JSObject * 0x000387c8, JSScript * 0x004249f8,
JSStackFrame * 0x00000000, unsigned int 0x00000000, long * 0x0013fecc) line 1393
+ 19 bytes
JS_ExecuteScript(JSContext * 0x000371b8, JSObject * 0x000387c8, JSScript *
0x004249f8, long * 0x0013fecc) line 3842 + 25 bytes
Process(JSContext * 0x000371b8, JSObject * 0x000387c8, char * 0x00032d56) line
223 + 22 bytes
ProcessArgs(JSContext * 0x000371b8, JSObject * 0x000387c8, char * * 0x00032cc4,
int 0x00000006) line 426 + 23 bytes
main(int 0x00000006, char * * 0x00032cc4, char * * 0x00033188) line 2552 + 21 bytes
JS! mainCRTStartup + 227 bytes
KERNEL32! 7c816d4f()
(Reporter)

Updated

12 years ago
Keywords: regression
Summary: E4X - JS_ASSERT @ js_Interpret, line 5070 → E4X - JS_ASSERT @ js_Interpret, line 5070
(Assignee)

Comment 1

12 years ago
This one's not a bogus assertion, it's a nasty bug in how the JSOP_SETSP emitted
at the start of the catch and/or finally clauses mixes badly with E4X's
filtering predicate expression.  The code generator has to know that the
filtering predicate is executed by an inner interpreter activation that uses the
same operand stack as the outer interpreter activation (the one that executes
the script containing the filtering predicate).

/be
Assignee: general → brendan
Flags: blocking1.8b5+
Keywords: js1.6
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta5
(Assignee)

Comment 2

12 years ago
Created attachment 197246 [details] [diff] [review]
proposed minimal fix

This is a bit ugly, but it works.  The !mark => XML filtering predicate
execution coupling is an XXX to reconsider later.  This fix should go into
1.8b5 shortly.

/be
Attachment #197246 - Flags: superreview?(shaver)
Attachment #197246 - Flags: review?(mrbkap)
(Assignee)

Comment 3

12 years ago
(In reply to comment #1)
> This one's not a bogus assertion, it's a nasty bug in how the JSOP_SETSP emitted
> at the start of the catch and/or finally clauses mixes badly with E4X's
> filtering predicate expression.

True so far.

> The code generator has to know that the
> filtering predicate is executed by an inner interpreter activation that uses the
> same operand stack as the outer interpreter activation (the one that executes
> the script containing the filtering predicate).

False diagnosis on my part -- the code generator can't help here, since only one
script is emitted for a function or top-level script that uses filtering
predicate expressions, and that script includes the expressions' bytecodes.  The
patch is based on the correct diagnosis: nesting an interpreter activation to
execute a filtering predicate means suppressing exception catching until we
unwind to the outer interpreter.

/be
Status: NEW → ASSIGNED
Comment on attachment 197246 [details] [diff] [review]
proposed minimal fix

r=mrbkap
Attachment #197246 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 5

12 years ago
Here is where I regret choosing to implement filtering predicates other than yb
generating bytecode in the containing script that does not require nesting an
interpreter activation that shares the top operand stack frame.  JSOP_FILTER
would change into a setup bytecode followed by an iterator update branch combo,
sort of like the for-in stuff.  JSOP_ENDFILTER would be a backward jump to the
iterator update test.

I may hack this up while traveling.

/be
Comment on attachment 197246 [details] [diff] [review]
proposed minimal fix

sr=shaver, want to file a bug on the XXX?
Attachment #197246 - Flags: superreview?(shaver) → superreview+
(Assignee)

Comment 7

12 years ago
Fixed on the trunk.  Let's see how the followup bug 309894 goes before trying
for the 1.8 branch, so we can choose between minimal hack-fix (this bug's patch)
and the right, forward-compatible bytecoded fix.

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

12 years ago
I just checked in fixes to JS_LIKELY abusage in jsinterp.c on the trunk:

revision 3.192
date: 2005/09/26 18:48:39;  author: brendan%mozilla.org;  state: Exp;  lines: +2 -2
Fix pointer testing via JS_LIKELY (rather fix a few callers than put cvs diff
jsinterp.c inside the macro...

/be
Brendan: we want to land this on the branch tomorrow morning (AM pacific, Sep
28), to take this assertion/crash off the radar for 1.5b2.  Do you have a
riskless patch up your sleeve for the bytecoded variant, or should we make that
change and the anyname-as-atom serialization change as part of the same XDR
version bump, on the trunk only?
Going to verify the delta between branch and trunk and land it on
MOZILLA_1_8_BRANCH in a little while.
Comment on attachment 197246 [details] [diff] [review]
proposed minimal fix

Approving on behalf of schrep and brendan and me.
Attachment #197246 - Flags: approval1.8b5+

Comment 12

12 years ago
Need get this landed before time runs out. 
It looks like shaver checked this into the branch already:
3.181.2.10 <shaver@mozilla.org> 2005-09-28 13:08
309852: hack around XML filtering predicate expression design flaw, patch from
/be, r=mrbkap, sr=shaver, a=schrep/shaver/brendan.
Keywords: fixed1.8
(Reporter)

Updated

12 years ago
Flags: testcase-
You need to log in before you can comment on or make changes to this bug.