I can't reproduce this anymore. I'm optimistically marking it as a dupe of bug 349493. *** This bug has been marked as a duplicate of 349493 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Created attachment 236194 [details] [diff] [review] fix So the constant folder has to update the unique down-pointer from parent to child when it moves a JSParseNode due to a constant condition selecting a then or else expression or clause. But for TOK_ARRAYCOMP, there's an up-pointer several nodes down in the TOK_ARRAYPUSH node, pn_array, that needs fixing. Otherwise we never point from two nodes to one -- the AST is a tree except for this cyclic up link, and there's no need for multiple connections in general. So I'm not going to mark a FIXME here, since I do not expect more up-pointers to be added to JSParseNode, so there's no point in generalizing. /be
Assignee: general → brendan
Status: REOPENED → ASSIGNED
Attachment #236194 - Flags: review?(mrbkap)
Created attachment 236340 [details] [diff] [review] altern-patch I like better This preserves the single-pointer-to-JSParseNode-from-any-other-JSParseNode (where the other node is always the parent, and pn_next does not count for the constant ? or if condition case) property. If you like it better too, please retract r+ on other patch and obsolete it, and r+ this one. It fixes the bug, using the nearest C equivalent to a statically scoped outer function variable (cg->arrayCompSlot). /be
Attachment #236340 - Flags: review?(mrbkap)
Comment on attachment 236340 [details] [diff] [review] altern-patch I like better Yeah, this is better.
Attachment #236340 - Flags: review?(mrbkap) → review+
Fixed on trunk. /be
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → FIXED
Attachment #236340 - Flags: approval1.8.1?
(In reply to comment #2) > > obj has been observed to be 0x00000000 or 0x80000000 (causing a segfault). i believe in some cases 0x80000000 may point to used heap - if one consumes enough memory.
Comment on attachment 236340 [details] [diff] [review] altern-patch I like better a=beltzner on behalf of 181drivers
Attachment #236340 - Flags: approval1.8.1? → approval1.8.1+
on linux 2.6 creating 2 js with byte size 256MB each makes 0x80000000 mapped on the heap.
Checking in regress-349653.js; /cvsroot/mozilla/js/tests/js1_5/Regress/regress-349653.js,v <-- regress-349653.js initial revision: 1.1
Fixed on the 1.8 branch too. /be
verified fixed 1.9 20060901 windows/mac*/linux
Status: RESOLVED → VERIFIED
verified fixed 1.8 2006090118 windows/mac*/linux
Keywords: fixed1.8.1 → verified1.8.1
the test was originally misplaced. Removing js1_5/Regress/regress-349653.js; /cvsroot/mozilla/js/tests/js1_5/Regress/regress-349653.js,v <-- regress-349653.js new revision: delete; previous revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/js1_7/block/regress-349653.js,v done Checking in js1_7/block/regress-349653.js; /cvsroot/mozilla/js/tests/js1_7/block/regress-349653.js,v <-- regress-349653.js initial revision: 1.1 done
Flags: blocking126.96.36.199? → blocking188.8.131.52-
Whiteboard: [sg:investigate] → [sg:investigate] js1.7
You need to log in before you can comment on or make changes to this bug.