Earth Day Recycling for Fun Kids - Assertion failure: RecycleFuncNameKids, at ../jsparse.cpp:444

VERIFIED FIXED in mozilla1.9.1b4

Status

()

Core
JavaScript Engine
P1
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: bc, Assigned: brendan)

Tracking

(4 keywords)

1.9.1 Branch
mozilla1.9.1b4
x86
All
assertion, regression, testcase, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
e4x/GC/regress-313952-02.js
e4x/GC/regress-357063-01.js
e4x/GC/regress-357063-02.js
e4x/Regress/regress-369740.js
e4x/Regress/regress-370048-01.js
e4x/Regress/regress-370048-02.js
e4x/Regress/regress-371369.js
e4x/Regress/regress-373082.js
e4x/XML/regress-376773.js
e4x/XMLList/13.5.4.4.js
e4x/extensions/regress-312196.js

Assertion failure: RecycleFuncNameKids, at ../jsparse.cpp:444

http://hg.mozilla.org/tracemonkey/rev/ab3af3308c0e
Flags: in-testsuite+
Flags: blocking1.9.1?
pn_type == FUNCTION
pn_arity == 0 (PN_NULLARY)
Looking, though the parser isn't my usual stomping grounds.  Feel free to steal if this is something obvious.
Assignee: general → jorendorff
(Assignee)

Comment 3

9 years ago
This is mine, sorry for the trouble. I was flying fast yesterday :-(.

E4X segregates methods from other properties such that calling x.length() on an XML or XMLList instance x does not go through property lookup, rather it jumps to the prototype (the spec is not good here). But this means you can't extract E4X methods, do things like x.someE4XMethod.apply(thisObj, args), etc. So I added the built-in function namespace, denoted by that keyword, enabling:

x.function::someE4XMethod.apply(thisObj, args)

The AST uses TOK_FUNCTION with zero arity. Just need to handle the case with grace instead of asserting.

/be
Assignee: jorendorff → brendan
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9.1b4
(Assignee)

Comment 4

9 years ago
Blocked bug 489079 so this should be marked with the same blocking status, P1 or P2, etc. Feel free to mark it for me!

/be
(Reporter)

Updated

9 years ago
Priority: -- → P1
(Assignee)

Updated

9 years ago
Hardware: x86 → All
(Assignee)

Comment 5

9 years ago
e4x/XMLList/13.5.4.4.js

does not assertbotch for me. Bob, are you testing shell or browser? Same assert? If so, what's different between our setups?

/be
(Assignee)

Comment 6

9 years ago
Harmless in opt builds, so need not block. DEBUG build users won't generally use E4X. Let's hope Mozilla's caldav code does not use function::foo.

I'll fix in tm and m-c ASAP.

/be
Priority: P1 → P2
(Assignee)

Comment 7

9 years ago
Created attachment 374152 [details] [diff] [review]
fix
Attachment #374152 - Flags: review?(mrbkap)

Updated

9 years ago
Attachment #374152 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/tracemonkey/rev/4b814acb49b0
http://hg.mozilla.org/mozilla-central/rev/c762f337c3c4

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey
(Reporter)

Comment 9

9 years ago
(In reply to comment #5)
> e4x/XMLList/13.5.4.4.js

sorry, copy/paste error. that was a different one that I ended up not being able to reproduce on linux or mac.
Priority: P2 → P1
Hardware: All → x86

Updated

9 years ago
Flags: blocking1.9.1? → blocking1.9.1+
(Reporter)

Comment 12

9 years ago
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.