Last Comment Bug 704795 - Assertion failure: isGCThing(), at ../../jsapi.h:536
: Assertion failure: isGCThing(), at ../../jsapi.h:536
Status: RESOLVED FIXED
js-triage-done
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla11
Assigned To: Bill McCloskey (:billm)
:
Mentors:
Depends on:
Blocks: langfuzz 641027
  Show dependency treegraph
 
Reported: 2011-11-23 04:29 PST by Christian Holler (:decoder)
Modified: 2013-01-14 08:37 PST (History)
4 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (2.54 KB, patch)
2011-11-29 16:21 PST, Bill McCloskey (:billm)
no flags Details | Diff | Splinter Review
fix v2 (2.62 KB, patch)
2011-12-06 16:48 PST, Bill McCloskey (:billm)
bhackett1024: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2011-11-23 04:29:03 PST
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 Gary Kwong [:gkw] [:nth10sd] 2011-11-29 15:31:50 PST
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)
Comment 2 Bill McCloskey (:billm) 2011-11-29 16:21:26 PST
Created attachment 577788 [details] [diff] [review]
fix

I couldn't reproduce the problem in comment 0, but the test in comment 1 worked. It was a dumb mistake.
Comment 3 Christian Holler (:decoder) 2011-11-29 16:25:47 PST
(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.
Comment 4 Bill McCloskey (:billm) 2011-11-29 16:35:36 PST
(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 Brian Hackett (:bhackett) 2011-11-30 08:24:19 PST
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).
Comment 6 Bill McCloskey (:billm) 2011-12-06 16:48:23 PST
Created attachment 579530 [details] [diff] [review]
fix v2

Yes, you're right.
Comment 8 Ed Morley [:emorley] 2011-12-08 08:54:59 PST
https://hg.mozilla.org/mozilla-central/rev/a48fe9aef820
Comment 9 Christian Holler (:decoder) 2013-01-14 08:37:59 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug704795.js.

Note You need to log in before you can comment on or make changes to this bug.