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

VERIFIED FIXED in mozilla1.9beta4

Status

()

P1
critical
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: jruderman, Assigned: brendan)

Tracking

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

Trunk
mozilla1.9beta4
x86
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 303923 [details]
testcase (triggers a fatal assertion when loaded)

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

11 years ago
Created attachment 303924 [details]
stack trace
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
(Reporter)

Comment 2

11 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

11 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?)

Updated

11 years ago
Flags: tracking1.9? → blocking1.9?

Updated

11 years ago
Assignee: general → brendan
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Assignee)

Updated

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

Updated

11 years ago
Duplicate of this bug: 418989
(Assignee)

Comment 6

11 years ago
Created attachment 306800 [details] [diff] [review]
fix, passes js and mochi tests
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

11 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

11 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
Last Resolved: 11 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/?

Comment 11

11 years ago
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
You need to log in before you can comment on or make changes to this bug.