Closed Bug 1257045 Opened 8 years ago Closed 8 years ago

Assertion failure: comp == compartment || runtime()->isAtomsCompartment(comp) || (srcKind == JS::TraceKind::Object && InCrossCompartmentMap(static_cast<JSObject*>(src), tenured, thing.kind())), at js/src/jsgc.cpp:390

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox47 --- wontfix
firefox48 --- fixed

People

(Reporter: gkw, Unassigned)

References

Details

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

Attachments

(1 file)

The following testcase crashes on mozilla-central revision f0c0480732d3 (build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-threads --no-baseline --no-ion):

fullcompartmentchecks(true);
var g = newGlobal();
var dbg = new Debugger(g);
dbg.onNewScript = (function(script) {
    s = script;
})
g.eval(`Wasm.instantiateModule(wasmTextToBinary('(module (func) (export "" 0))'));`);
s.source;

Backtrace:

0   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005c8b38 CompartmentCheckTracer::onChild(JS::GCCellPtr const&) + 1128 (jsgc.cpp:3899)
1   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001008f8054 JS::CallbackTracer::onObjectEdge(JSObject**) + 52 (TracingAPI.h:108)
2   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001009e99ef JSObject* DoCallback<JSObject*>(JS::CallbackTracer*, JSObject**, char const*) + 63 (TracingAPI.h:220)
3   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001006c30ba DebuggerScript_trace(JSTracer*, JSObject*) + 282 (jsobj.h:122)
4   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005ec110 JSObject::traceChildren(JSTracer*) + 64 (jsobj.cpp:3796)
5   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001009e5988 js::TraceChildren(JSTracer*, void*, JS::TraceKind) + 40 (Tracer.cpp:127)
6   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005c8d41 js::gc::GCRuntime::checkForCompartmentMismatches() + 433 (jsgc.cpp:3917)
7   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005c8f1c js::gc::GCRuntime::beginMarkPhase(JS::gcreason::Reason) + 60 (jsgc.cpp:3954)
8   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005d495f js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) + 719 (jsgc.cpp:6037)
9   js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005d585c js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) + 460 (jsgc.cpp:6328)
10  js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005d6215 js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) + 757 (jsgc.cpp:6428)
11  js-dbg-64-dm-clang-darwin-f0c0480732d3	0x00000001005c5e26 js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason) + 86 (jsgc.cpp:6487)
12  js-dbg-64-dm-clang-darwin-f0c0480732d3	0x000000010057e6ae js::DestroyContext(JSContext*, js::DestroyContextMode) + 462 (Utility.h:384)
13  js-dbg-64-dm-clang-darwin-f0c0480732d3	0x0000000100006196 main + 12886 (js.cpp:7315)
14  js-dbg-64-dm-clang-darwin-f0c0480732d3	0x0000000100000ff4 start + 52
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160311212827" and the hash "3e871f2d5b4bb29d788201568d68fe48a84113f9".
The "bad" changeset has the timestamp "20160311214427" and the hash "d89e927c2b7b3b9bd660f8be0a1245c46f64a696".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e871f2d5b4bb29d788201568d68fe48a84113f9&tochange=d89e927c2b7b3b9bd660f8be0a1245c46f64a696
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/eb0831a7ef13
user:        Shu-yu Guo
date:        Fri Mar 11 21:43:21 2016 -0800
summary:     Bug 1254893 - Fire onNewScript for new wasm modules. (r=jimb)

Shu-yu, is bug 1254893 a likely regressor?
Blocks: 1254893
I was a fool to try to take shortcuts: I thought the CCW key kind was only used
to determine what the wrapped thing is that we should trace. It's actually also
used as part of the key (duh) in the CCW table. The bug here is that since I
gave both wasm Debugger.Script and wasm Debugger.Source the key kind of
DebuggerObject, which wrapper is gotten later would override the earlier one in
the CCW table.
Attachment #8731550 - Flags: review?(jimb)
Attachment #8731550 - Flags: review?(jimb) → review+
Backed out for jit-test failures.
https://hg.mozilla.org/integration/mozilla-inbound/rev/c7914f20970a

https://treeherder.mozilla.org/logviewer.html#?job_id=24072623&repo=mozilla-inbound
TEST-UNEXPECTED-FAIL | tests\jit-test\jit-test\tests\debug\bug1257045.js | C:\slave\test\build\tests\jit-test\jit-test\tests\debug\bug1257045.js line 7 > eval:1:1 Error: WebAssembly is not supported on the current device. (code 3, args "--baseline-eager --no-fpu")
https://hg.mozilla.org/mozilla-central/rev/4f2f430361c4
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Wasm only. Since wasm is off by default, Luke has advised that we're not uplifting wasm related bugs. WONTFIX 47.
See Also: → 1546817
You need to log in before you can comment on or make changes to this bug.