"Assertion failure: protoIndex != 1 || OBJ_GET_PROTO(cx, obj) == pobj" with <svg:use>, <xul:listbox>, CSS

VERIFIED FIXED in mozilla1.9beta4

Status

()

defect
P1
critical
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: jruderman, Assigned: brendan)

Tracking

(Blocks 2 bugs, {assertion, regression, testcase})

Trunk
mozilla1.9beta4
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

12 years ago
Assertion failure: protoIndex != 1 || OBJ_GET_PROTO(cx, obj) == pobj, at /Users/jruderman/trunk/mozilla/js/src/jsinterp.c:223

The testcase consists of SVG, XUL, and CSS.  Strange to see that combination triggering an assertion in the JavaScript engine.

The assertion is part of code added in bug 365851 "return of the property cache".

Nightly builds don't explode.
Reporter

Comment 1

12 years ago
Posted file stack trace
Reporter

Updated

12 years ago
Flags: blocking1.9?
Reporter

Comment 2

12 years ago
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?
Reporter

Comment 4

12 years ago
(gdb) p protoIndex
$1 = 1
(gdb) p pobj
$2 = (JSObject *) 0x3d1861e0
(gdb) p obj
$3 = (JSObject *) 0x3d186900
(gdb) p/x obj->fslots[0]
$5 = 0x3d1871e0
(gdb) p/x obj->fslots[1]
$6 = 0x3d1868e0
(gdb) p/x obj->fslots[2]
$7 = 0x3ba509a5
(gdb) p/x obj->fslots[3]
$8 = 0x3d2a20e1

(Can't you reproduce this yourself using the testcase?)
Flags: tracking1.9? → blocking1.9?
Assignee: general → brendan
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee

Updated

12 years ago
Status: NEW → ASSIGNED
Priority: P2 → P1
Target Milestone: --- → mozilla1.9beta4
Assignee

Updated

12 years ago
Duplicate of this bug: 418989
Assignee

Comment 6

12 years ago
Attachment #306800 - Flags: review?(shaver)
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?
Attachment #306800 - Flags: review?(shaver)
Attachment #306800 - Flags: review+
Attachment #306800 - Flags: approval1.9b4+
Reporter

Comment 8

12 years ago
I'd just check in the testcase as a crashtest, unless Brendan knows how to test this bug more directly.
Assignee

Comment 9

12 years ago
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

Updated

11 years ago
Depends on: 420612
Reporter

Comment 10

11 years ago
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?
Reporter

Comment 12

11 years ago
Crashtest checked in using waldo's suggested location.
Flags: in-testsuite+
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
Depends on: 427196
You need to log in before you can comment on or make changes to this bug.