I'm hitting this assertion very frequently when fuzzing.
Can you see what protoIndex is, and what the prototype relationship is between obj and pobj when you trip this assertion?
(gdb) p protoIndex $1 = 1 (gdb) p pobj $2 = (JSObject *) 0x3d1861e0 (gdb) p obj $3 = (JSObject *) 0x3d186900 (gdb) p/x obj->fslots $5 = 0x3d1871e0 (gdb) p/x obj->fslots $6 = 0x3d1868e0 (gdb) p/x obj->fslots $7 = 0x3ba509a5 (gdb) p/x obj->fslots $8 = 0x3d2a20e1 (Can't you reproduce this yourself using the testcase?)
Assignee: general → brendan
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Status: NEW → ASSIGNED
Priority: P2 → P1
Target Milestone: --- → mozilla1.9beta4
Comment on attachment 306800 [details] [diff] [review] fix, passes js and mochi tests r+a=shaver. I wish we could prohibit late JS_SetParent programmatically, but I can't think of how we would. Jesse: can you see how to turn the assertion-triggering example into mochi-fodder?
I'd just check in the testcase as a crashtest, unless Brendan knows how to test this bug more directly.
Shapes are capabilities, so there's no correctness bug if someone changes the scope chain from a getter or setter, so as to invalidate the fill that follows soon after the getter or setter returns. Fixed: js/src/jsinterp.c 3.457 Crashtest sounds good. I'll think about better ways to test. /be
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Should I create js/tests/crashtests/ or js/src/crashtests/?
Neither's great; js/ should really be its own world (sadly modulo js/src/xpconnect, which I wish were outside the js/ directory) in my opinion. Maybe dump it in js/src/xpconnect/crashtests?
Crashtest checked in using waldo's suggested location.
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032615 Firefox/3.0b5pre ID:2008032615 - no assertion on the testcase --> Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.