Closed Bug 704795 Opened 14 years ago Closed 14 years ago

Assertion failure: isGCThing(), at ../../jsapi.h:536

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla11

People

(Reporter: decoder, Assigned: billm)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: js-triage-done)

Attachments

(1 file, 1 obsolete file)

The following test asserts on mozilla-central revision 6f998cc964be (options -m -n -a): gczeal(4); function setprop() { var obj = { a:({ } ) }; var obj2 = { b:-1, a:-1 }; for (var i = 0; i < 20; (length(resultsY.global0, 42))) { obj2.b = obj.a = i; } } assertEq(setprop(), "19,-1,19"); Guessing this is only related to incremental GC due to gczeal(4), therefore not s-s.
Another testcase: Function("\ gczeal(4,false);\ function f(){\ \"use strict\";\ this.x = Object\ }\ for each(y in[0,0]){\ try{\ new f\ }\ catch(e){}\ }\ ")() autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 80143:65dcb557b3f6 user: Bill McCloskey date: Fri Aug 05 10:25:23 2011 -0700 summary: Bug 641027 - Add snapshot-based verifier for JS write barriers (r=luke)
Blocks: 641027
Keywords: regression
OS: Linux → All
Hardware: x86 → All
Attached patch fix (obsolete) — Splinter Review
I couldn't reproduce the problem in comment 0, but the test in comment 1 worked. It was a dumb mistake.
Attachment #577788 - Flags: review?(bhackett1024)
Whiteboard: js-triage-needed → js-triage-done
(In reply to Bill McCloskey (:billm) from comment #2) > I couldn't reproduce the problem in comment 0, but the test in comment 1 > worked. I think the test in comment 0 might be 32 bit only.
(In reply to Christian Holler (:decoder) from comment #3) > (In reply to Bill McCloskey (:billm) from comment #2) > > I couldn't reproduce the problem in comment 0, but the test in comment 1 > > worked. > > I think the test in comment 0 might be 32 bit only. Ah, thanks. I can reproduce now, and the patch I posted does not fix the problem. I'll start a new bug for the comment 0 testcase.
Comment on attachment 577788 [details] [diff] [review] fix Mmm, the testing here still doesn't look right. In the !isObject case, the write barrier is always performed and the address passed in is the payload + fixed slot offset. But no object test has occurred, and the payload may not be an object's address. I think you need to test for an object here, and in the non-object case skip the barrier entirely (the setprop will go through a stub which will hit barriers in the VM).
Attachment #577788 - Flags: review?(bhackett1024)
Attached patch fix v2Splinter Review
Yes, you're right.
Attachment #577788 - Attachment is obsolete: true
Attachment #579530 - Flags: review?(bhackett1024)
Attachment #579530 - Flags: review?(bhackett1024) → review+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug704795.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: