Last Comment Bug 706316 - Assertion failure: isGCThing(), at ../../jsapi.h:536
: Assertion failure: isGCThing(), at ../../jsapi.h:536
Status: RESOLVED FIXED
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla11
Assigned To: David Mandelin [:dmandelin]
:
:
Mentors:
: 708091 (view as bug list)
Depends on:
Blocks: langfuzz 641027
  Show dependency treegraph
 
Reported: 2011-11-29 16:36 PST by Bill McCloskey (:billm)
Modified: 2013-01-14 08:25 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (6.99 KB, patch)
2011-12-06 17:10 PST, David Mandelin [:dmandelin]
dvander: review+
Details | Diff | Splinter Review

Description Bill McCloskey (:billm) 2011-11-29 16:36:46 PST
+++ This bug was initially created as a clone of Bug #704795 +++

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 David Mandelin [:dmandelin] 2011-12-06 11:56:22 PST
On m-i tip (39b7b2f8e840), I get a different assertion:

Assertion failure: static_cast<Cell *>(thing)->isMarked(), at c:/sources/mozilla-inbound/js/src/jsgc.cpp:3530

For that assert, the test case can be reduced to:

gczeal(4);
function setprop() {
  for (var i = 0; i < 20; (length(resultsY.global0, 42))) {
  }
}
assertEq(setprop(), "19,-1,19");

and doesn't require any options to fail. It's asserting in a call to the verifier at the end of the exception-throwing path in the interpreter.
Comment 2 David Mandelin [:dmandelin] 2011-12-06 12:03:17 PST
I still get the same behavior as comment 1 on the originally reported m-c revision. This is 32-bit on Win 7 if that could make a difference.
Comment 3 David Mandelin [:dmandelin] 2011-12-06 17:08:00 PST
*** Bug 708091 has been marked as a duplicate of this bug. ***
Comment 4 David Mandelin [:dmandelin] 2011-12-06 17:10:25 PST
Created attachment 579533 [details] [diff] [review]
Patch

The problem, as Bill explained to me, was that the register sync that happens before the call was stepping on the register that holds obj. I solved it like this:

- Pin the obj register.
- Fix ImmutableSync not to step on pinned registers.
  - Primarily, I just had to make it not allocate pinned registers and not add them to the available set.
  - I also changed the sync code that initializes avail not to add pinned registers
  - I added an assert to protect against a pinned reg getting allocated.
Comment 5 David Mandelin [:dmandelin] 2011-12-06 18:56:15 PST
http://hg.mozilla.org/integration/mozilla-inbound/rev/3080aa9f675d
Comment 6 Ed Morley [:emorley] 2011-12-07 02:29:53 PST
https://hg.mozilla.org/mozilla-central/rev/3080aa9f675d
Comment 7 Christian Holler (:decoder) 2013-01-14 08:25:17 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug706316.js.

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