Closed Bug 1243151 Opened 9 years ago Closed 9 years ago

crash in js::TenuringTracer::traceObject

Categories

(Core :: JavaScript Engine: JIT, defect)

Product:
Core
Component:
JavaScript Engine: JIT
Version:
45 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1295031
Tracking Flags:
Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- unaffected
firefox-esr45 --- affected
firefox50 --- unaffected
firefox51 --- fixed

People

(Reporter: whimboo, Unassigned)

References

(
URL
)

Details

(Keywords: crash, sec-critical)

Crash Data

Attachments

(1 file)

securegoldenkeyboot.zip
210.32 KB, application/x-zip-compressed
Details
Firefox crashed when I tried to open the following URL: https://www.bing.com/maps/default.aspx?name=Ardesia+Therme&cp=50.4501686096191%7e11.6423006057739&ss=ypid.YN6740x11066227124339407739&ppois=50.4501686096191_11.6423006057739_Ardesia+Therme So far the crash is not reproducible. crash report: bp-44f72161-fabb-4c0c-94a0-195bd2160126 Crash Reason SIGSEGV Crash Address 0x0 Top 10 frames from the stack: 0 libxul.so js::TenuringTracer::traceObject(JSObject*) js/src/gc/Marking.cpp 1 libxul.so js::Nursery::collectToFixedPoint(js::TenuringTracer&, js::gc::TenureCountCache&) js/src/gc/Marking.cpp 2 libxul.so js::Nursery::collect(JSRuntime*, JS::gcreason::Reason, mozilla::Vector<js::ObjectGroup*, 0ul, js::SystemAllocPolicy>*) js/src/gc/Nursery.cpp 3 libxul.so js::gc::GCRuntime::minorGCImpl(JS::gcreason::Reason, mozilla::Vector<js::ObjectGroup*, 0ul, js::SystemAllocPolicy>*) js/src/jsgc.cpp 4 libxul.so js::gc::GCRuntime::evictNursery(JS::gcreason::Reason) js/src/gc/GCRuntime.h 5 libxul.so js::GlobalHelperThreadState::mergeParseTaskCompartment(JSRuntime*, js::ParseTask*, JS::Handle<js::GlobalObject*>, JSCompartment*) js/src/jsgcinlines.h 6 libxul.so js::GlobalHelperThreadState::finishParseTask(JSContext*, JSRuntime*, void*) js/src/vm/HelperThreads.cpp 7 libxul.so JS::FinishOffThreadScript(JSContext*, JSRuntime*, void*) js/src/jsapi.cpp 8 libxul.so nsJSUtils::EvaluateString(JSContext*, JS::SourceBufferHolder&, JS::Handle<JSObject*>, JS::CompileOptions&, nsJSUtils::EvaluateOptions const&, JS::MutableHandle<JS::Value>, void**) dom/base/nsJSUtils.cpp 9 libxul.so nsJSUtils::EvaluateString(JSContext*, JS::SourceBufferHolder&, JS::Handle<JSObject*>, JS::CompileOptions&, void**) dom/base/nsJSUtils.cpp 10 libxul.so nsScriptLoader::EvaluateScript(nsScriptLoadRequest*, JS::SourceBufferHolder&) dom/base/nsScriptLoader.cpp
Crash volume for signature 'js::TenuringTracer::traceObject': - nightly (version 50): 0 crash from 2016-06-06. - aurora (version 49): 1 crash from 2016-06-07. - beta (version 48): 16 crashes from 2016-06-06. - release (version 47): 154 crashes from 2016-05-31. - esr (version 45): 5 crashes from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 0 - aurora 1 0 0 0 0 0 0 - beta 2 3 1 5 2 0 0 - release 17 26 13 32 23 25 4 - esr 0 0 0 1 0 0 2 Affected platforms: Windows, Mac OS X, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
I hit this reproducibly by loading https://rol.im/securegoldenkeyboot/ on current Nightly (OS X 10.11.6, Macbook Air 13" late-2011).
(In reply to Robin Whittleton from comment #3) > I hit this reproducibly by loading https://rol.im/securegoldenkeyboot/ on > current Nightly (OS X 10.11.6, Macbook Air 13" late-2011). Thank you for the heads up! I'll take a look right now.
I started making a reduced test case but didn't get very far. It was crashing inside the XM player though, you can rip out all the content, styling and canvas operations.
It didn't crash for me on the first few reloads. I'm currently updating to 10.11.6 to make our configurations exactly equal.
I got it to reproduce after upgrading. Making a debug build now to see if it hits any assertions before crashing.
We are actually hitting this assertion: Hit MOZ_CRASH(Unhandled JSCLASS_SKIP_NURSERY_FINALIZE Class) at /Users/terrence/moz/branch/2/js/src/gc/Marking.cpp:2354 Now to figure out how to make lldb follow forks.
Here is a stack: * thread #1: tid = 0x14142, 0x0000000105255111 XUL`JSObject::allocKindForTenure(this=<unavailable>, nursery=<unavailable>) const + 1985 at jsobj.cpp:3731, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000105255111 XUL`JSObject::allocKindForTenure(this=<unavailable>, nursery=<unavailable>) const + 1985 at jsobj.cpp:3731 frame #1: 0x00000001056c10eb XUL`js::TenuringTracer::moveToTenured(this=0x00007fff5f8dfb08, src=0x000000010e500220) + 123 at Marking.cpp:2212 frame #2: 0x00000001056c0f91 XUL`void js::TenuringTracer::traverse<JSObject>(this=<unavailable>, objp=<unavailable>) + 97 at Marking.cpp:2043 frame #3: 0x00000001056c2425 XUL`js::TenuringTracer::traceObject(JSObject*) [inlined] void TenuringFunctor::operator(thing=<unavailable>, mover=<unavailable>)<JSObject*>(JSObject**, js::TenuringTracer&) + 965 at Marking.cpp:2255 frame #4: 0x00000001056c241d XUL`js::TenuringTracer::traceObject(JSObject*) + 15 at Marking.cpp:1345 frame #5: 0x00000001056c240e XUL`js::TenuringTracer::traceObject(JSObject*) + 397 at Marking.cpp:1319 frame #6: 0x00000001056c2281 XUL`js::TenuringTracer::traceObject(this=0x00007fff5f8dfb08, obj=<unavailable>) + 545 at Marking.cpp:2263 frame #7: 0x00000001056c1f18 XUL`js::Nursery::collectToFixedPoint(this=<unavailable>, mover=0x00007fff5f8dfb08, tenureCounts=0x00007fff5f8dfa00) + 72 at Marking.cpp:2239 frame #8: 0x00000001056cabb7 XUL`js::Nursery::collect(this=0x000000010e446650, rt=0x000000010e4461c8, reason=FULL_STORE_BUFFER, pretenureGroups=0x00007fff5f8dfc10) + 1639 at Nursery.cpp:595 frame #9: 0x00000001051f1dbb XUL`js::gc::GCRuntime::minorGC(this=0x000000010e4465f8, reason=FULL_STORE_BUFFER, phase=<unavailable>) + 219 at jsgc.cpp:6474 frame #10: 0x00000001051e0131 XUL`js::gc::GCRuntime::gcIfRequested(this=0x000000010e4465f8) + 33 at jsgc.cpp:6528 frame #11: 0x00000001054542ac XUL`JSRuntime::handleInterrupt(JSContext*) [inlined] InvokeInterruptCallback(JSContext*) + 26 at Runtime.cpp:545 frame #12: 0x0000000105454292 XUL`JSRuntime::handleInterrupt(this=<unavailable>, cx=0x000000010e446000) + 114 at Runtime.cpp:652 frame #13: 0x00000001050b1178 XUL`js::jit::CheckOverRecursedWithExtra(cx=0x000000010e446000, frame=<unavailable>, extra=<unavailable>, earlyCheck=<unavailable>) + 168 at VMFunctions.cpp:181 frame #14: 0x000000010b35b9db frame #15: 0x000000010b350e1d frame #16: 0x0000000104dc8879 XUL`EnterBaseline(cx=0x0000000000002044, data=0x00007fff5f8e0680) + 649 at BaselineJIT.cpp:155 frame #17: 0x0000000104dc8530 XUL`js::jit::EnterBaselineMethod(cx=0x000000010e446000, state=0x00007fff5f8e0800) + 400 at BaselineJIT.cpp:194 frame #18: 0x00000001053dd093 XUL`js::RunScript(cx=<unavailable>, state=<unavailable>) + 403 at Interpreter.cpp:389 frame #19: 0x00000001053ee08e XUL`js::InternalCallOrConstruct(cx=0x000000010e446000, args=<unavailable>, construct=<unavailable>) + 750 at Interpreter.cpp:471 frame #20: 0x00000001053ee98e XUL`js::Call(cx=<unavailable>, fval=<unavailable>, thisv=<unavailable>, args=0x00007fff5f8e0898, rval=<unavailable>) + 46 at Interpreter.cpp:517 frame #21: 0x000000010531ce2e XUL`js::Wrapper::call(this=<unavailable>, cx=0x000000010e446000, proxy=<unavailable>, args=0x00007fff5f8e0a98) const + 366 at Wrapper.cpp:165 frame #22: 0x00000001052c9852 XUL`js::CrossCompartmentWrapper::call(this=0x0000000106e707d8, cx=0x000000010e446000, wrapper=<unavailable>, args=0x00007fff5f8e0a98) const + 258 at CrossCompartmentWrapper.cpp:329 frame #23: 0x00000001052cfc81 XUL`js::Proxy::call(cx=0x000000010e446000, proxy=<unavailable>, args=0x00007fff5f8e0a98) + 241 at Proxy.cpp:401 frame #24: 0x00000001052d15e6 XUL`js::proxy_Call(cx=0x000000010e446000, argc=<unavailable>, vp=<unavailable>) + 166 at Proxy.cpp:690 frame #25: 0x00000001053ee29c XUL`js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) [inlined] js::CallJSNative(native=(XUL`js::proxy_Call(JSContext*, unsigned int, JS::Value*) at Proxy.cpp:686))(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 116 at jscntxtinlines.h:235 frame #26: 0x00000001053ee228 XUL`js::InternalCallOrConstruct(cx=0x000000010e446000, args=0x00007fff5f8e0be8, construct=<unavailable>) + 1160 at Interpreter.cpp:441 frame #27: 0x0000000104d92c31 XUL`js::jit::DoCallFallback(cx=0x000000010e446000, frame=0x00007fff5f8e0eb8, stub_=0x0000000160e7beb8, argc=0, vp=0x00007fff5f8e0e40, res=<unavailable>) + 1873 at BaselineIC.cpp:5981 frame #28: 0x000000010b358471
The name of the "non-native" clasp is: "\xffffffafG\xffffffbe\x05\x01". So I gather I'm looking at heap corruption of some sort.
The object pointer is coming out of an unboxed object, straight out of the JIT. Eric, could we get someone who is familiar with unboxed objects to take a look?
Flags: needinfo?(efaustbmo)
Note that this only reproduces with ionmonkey enabled. It runs fine (although extremely slowly) in the interpreter and in baseline.
Component: JavaScript: GC → JavaScript Engine: JIT
I tried to get this to repro on linux, without any success. Jan, you have a mac, right? Can you take a look?
Flags: needinfo?(efaustbmo) → needinfo?(jdemooij)
I think this might be the same issue as bug 1293244.
See Also: → 1293244
Group: javascript-core-security
This sounds bad, so I'm hiding it and marking it sec-critical.
Keywords: sec-critical
(In reply to Jon Coppeard (:jonco) from comment #14) > I think this might be the same issue as bug 1293244. Yup, I get the !IsProxy assert here. I'll try to get a standalone test for this.
Standalone copy of the website, this crashes Nightly on OS X.
I have an rr recording of this, but I'll try bisecting first.
Bisecting gives: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=505e6acd9c291504700a57ddf7e88f704f65da46&tochange=52a0d2d7639717858ce6868c19a37b95e7039736 In that range, it's most likely: cb1f1638d126 Sander Mathijs van Veen — Bug 1279992 - Inline constructor of typed arrays with non-compile-time known size r=jandem,Waldo
Flags: needinfo?(jdemooij)
This might be bug 1293258, I'll review that patch today.
Depends on: 1293258
I bisected the fix, the patch for bug 1295031 is in that range.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Depends on: 1295031
No longer depends on: 1293258
Should be fixed in 51 now from the patch in bug 1295031. It sounds like this may no longer affect 49 (Or never did, and the couple of crashes on 49 are from some other cause). Jan is that correct?
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
status-firefox49: affected → fix-optional
status-firefox51: --- → fixed
Flags: needinfo?(jdemooij)
Crash volume for signature 'js::TenuringTracer::traceObject': - nightly (version 51): 38 crashes from 2016-08-01. - aurora (version 50): 2 crashes from 2016-08-01. - beta (version 49): 5 crashes from 2016-08-02. - release (version 48): 33 crashes from 2016-07-25. - esr (version 45): 11 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 23 15 0 - aurora 0 2 0 - beta 2 3 0 - release 13 8 4 - esr 1 4 1 Affected platforms: Windows, Mac OS X, Linux Crash rank on the last 7 days: Browser Content Plugin - nightly #265 - aurora - beta #11635 - release #1728 - esr
status-firefox50: --- → affected
Yes this never affected 49 and 50.
status-firefox49: fix-optional → unaffected
status-firefox50: affected → unaffected
Flags: needinfo?(jdemooij)
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: