Closed Bug 1243151 Opened 6 years ago Closed 5 years ago

crash in js::TenuringTracer::traceObject

Categories

(Core :: JavaScript Engine: JIT, defect)

45 Branch
defect
Not set
critical

Tracking

()

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

People

(Reporter: whimboo, Unassigned)

References

()

Details

(Keywords: crash, sec-critical)

Crash Data

Attachments

(1 file)

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
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.
Duplicate of this bug: 1294669
Depends on: 1293258
I bisected the fix, the patch for bug 1295031 is in that range.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1295031
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?
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
Yes this never affected 49 and 50.
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.