1874577 - Crash in [@ JSObject::isCallable]

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[BugBot [:suhaib / :marco/ :calixte]]

Crash report: https://crash-stats.mozilla.org/report/index/d5bed6c5-8e83-4b70-9709-42a2d0240113

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  JSObject::isCallable const  js/src/vm/JSObject-inl.h:573
0  xul.dll  js::DeadProxyTargetValue  js/src/proxy/DeadObjectProxy.cpp:134
1  xul.dll  js::NewDeadProxyObject  js/src/proxy/DeadObjectProxy.cpp:149
2  xul.dll  JS::MutableHandle<JSObject*>::set  js/public/RootingAPI.h:716
2  xul.dll  JS::Compartment::getNonWrapperObjectForCurrentCompartment  js/src/vm/Compartment.cpp
2  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:384
3  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:434
3  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:458
4  xul.dll  JS_WrapPropertyDescriptor  js/src/jsfriendapi.cpp:183
4  xul.dll  xpc::JSXrayTraits::getOwnPropertyFromWrapperIfSafe  js/xpconnect/wrappers/XrayWrapper.cpp:299

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2023-11-20
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 3 crashes happened on null or near null memory address

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Iain Ireland [:iain]]

I've poked around at a variety of crash reports, and I haven't found anything actionable here.

There's something vaguely interesting going on, in that many of the crashes involve the offset 0x108: the crash report in comment 1 crashes at 0x0000000000000108, and there are also two crashes at 0x0000000100000108 and three at 0xfff9800000000108. The failing instruction is reported as "mov rax, qword [rax + 0x108]". So it looks like we have a pointer that we think should be an object of some sort, we try to access a field at offset 0x108, but we crash because it's actually null / undefined / null-with-one-bit-set. The weird part is that 0x108 is quite a large offset (264 bytes), and I can't find anything that big related to IsCallable.

Scratch that; while writing this up, I think I successfully reverse-engineered the disassembly. 0x108 is the offset of isCallable in the vtable for BaseProxyHandler. (It's the 34th virtual method in the class definition; using zero-indexing, 33 * 8 = 0x108.) So the problem in this case is simply that we've called into this code with an object that claims to be a proxy, but doesn't have a valid handler. That's probably memory corruption of some sort. Given that the 0x108 crashes are a relatively small subset of all these crashes, I'm willing to conclude that these crashes are flaky hardware / memory corruption elsewhere, and do not point to a bug in IsCallable. The crash rate seems stable, so we're probably just looking at background noise.

I don't think there's anything to be done here.