Closed Bug 1014972 Opened 10 years ago Closed 10 years ago

Assertion failure: location == gc::ChunkLocationNursery || location == gc::ChunkLocationTenuredHeap, at dist/include/js/HeapAPI.h

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla32
Tracking Status
firefox31 --- unaffected
firefox32 --- affected

People

(Reporter: gkw, Assigned: terrence)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(2 files)

Attached file stack
Function("\
    Array.buildPar(6947, (function() {\
        return {\
            a: new Function,\
            b1: function() {},\
            b2: function() {},\
            b3: function() {},\
            b4: function() {}\
        }\
    }));\
    selectforgc(new Object);\
")()

asserts js debug shell on m-c changeset b40296602083 with --ion-eager --ion-parallel-compile=off at Assertion failure: location == gc::ChunkLocationNursery || location == gc::ChunkLocationTenuredHeap, at dist/include/js/HeapAPI.h

My configure flags are:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --disable-tests --with-ccache --enable-threadsafe <other NSPR options>

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/a6cf64544f9b
user:        Terrence Cole
date:        Wed May 14 19:48:09 2014 -0700
summary:     Bug 1010655 - Always use the faster version of IsInsideNursery when possible; r=jonco

Setting s-s and sec-critical by default because this seems to be a gc issue.

Terrence, is bug 1010655 a likely regressor?
Flags: needinfo?(terrence)
Nope, pre-existing bustage in some debug code that I didn't even know existed. It happened not to trip over any assertions before, somehow.

This is only triggerable from the shell, not from the browser. What is our sec policy for such issues?
Assignee: nobody → terrence
Status: NEW → ASSIGNED
Attachment #8427458 - Flags: review?(jcoppeard)
Flags: needinfo?(terrence)
Group: core-security, javascript-core-security
Keywords: sec-critical
I removed the security sensitive flag because this is just a bug in a testing function.
Comment on attachment 8427458 [details] [diff] [review]
bug-1014972-v0.diff

Review of attachment 8427458 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit-test/tests/gc/bug-1014972.js
@@ +1,2 @@
> +Function("\
> +    Array.buildPar(6947, (function() {\

This might need a configuration check for parallel JS, except I don't think the parallel stuff is actually necessary to make this go bang.
Attachment #8427458 - Flags: review?(jcoppeard) → review+
Good catch on checking for PJS before running the code.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3e60960771e5
https://hg.mozilla.org/mozilla-central/rev/3e60960771e5
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: