Closed
Bug 704795
Opened 14 years ago
Closed 14 years ago
Assertion failure: isGCThing(), at ../../jsapi.h:536
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
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)
|
2.62 KB,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•14 years ago
|
||
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)
| Assignee | ||
Comment 2•14 years ago
|
||
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)
| Assignee | ||
Updated•14 years ago
|
Whiteboard: js-triage-needed → js-triage-done
| Reporter | ||
Comment 3•14 years ago
|
||
(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.
| Assignee | ||
Comment 4•14 years ago
|
||
(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 5•14 years ago
|
||
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)
| Assignee | ||
Comment 6•14 years ago
|
||
Yes, you're right.
Attachment #577788 -
Attachment is obsolete: true
Attachment #579530 -
Flags: review?(bhackett1024)
Updated•14 years ago
|
Attachment #579530 -
Flags: review?(bhackett1024) → review+
| Assignee | ||
Comment 7•14 years ago
|
||
Target Milestone: --- → mozilla11
Comment 8•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
| Reporter | ||
Comment 9•13 years ago
|
||
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.
Description
•