Closed Bug 489552 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: JavaScript Engine, defect, P1)

1.9.1 Branch
x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b4

People

(Reporter: bc, Assigned: brendan)

References

Details

(4 keywords, Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

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
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
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
Priority: -- → P1
Hardware: x86 → All
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
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
Attached patch fixSplinter Review
Attachment #374152 - Flags: review?(mrbkap)
Attachment #374152 - Flags: review?(mrbkap) → review+
http://hg.mozilla.org/tracemonkey/rev/4b814acb49b0
http://hg.mozilla.org/mozilla-central/rev/c762f337c3c4

/be
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey
(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
Flags: blocking1.9.1? → blocking1.9.1+
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.