1895035 - Crash in [@ js::PropMap::canHaveTable]

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/699fb5c9-cb18-4f03-b421-58a8e0240503

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  js::PropMap::canHaveTable const  js/src/vm/PropMap.h:488
0  xul.dll  js::PropMap::lookup  js/src/vm/PropMap-inl.h:128
0  xul.dll  js::NativeShape::lookup  js/src/vm/Shape-inl.h:53
0  xul.dll  js::NativeLookupOwnPropertyInline  js/src/vm/NativeObject-inl.h:764
0  xul.dll  js::NativeLookupPropertyInline  js/src/vm/NativeObject-inl.h:824
0  xul.dll  js::LookupPropertyPure  js/src/vm/JSObject.cpp:1732
0  xul.dll  CanAttachNativeGetProp  js/src/jit/CacheIR.cpp:617
0  xul.dll  js::jit::GetPropIRGenerator::tryAttachNative  js/src/jit/CacheIR.cpp:1147
0  xul.dll  js::jit::GetPropIRGenerator::tryAttachStub  js/src/jit/CacheIR.cpp:431
1  xul.dll  js::jit::TryAttachStub  js/src/jit/BaselineIC.cpp:504

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

• First crash report: 2024-03-01
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 7 crashes happened on null or near null memory address

Comment 1

[Iain Ireland [:iain]]

In the crash linked in comment 1, we load the prop map out of the shape and try to check its flags, but the prop map pointer is 0x00008e0cffffffff, which looks less like a prop map pointer and more like a couple of unrelated 32-bit values sitting next to each other in memory. My assumption is that there was something already wrong with the shape.

canHaveTable is extremely hot (23 billion hits per coverage run in searchfox). Skimming through the proto signatures, nothing in particular stands out. The crashes look like a reasonable distribution of the paths that I would expect to call this code. If there were a real bug here, I would expect either a higher crash rate, or a specific call stack that tends to trigger this more often. Given the lack of pattern and the low crash/execution ratio, I suspect that these crashes are mostly cosmic rays / bad RAM.

I also see that 47/133 of the crashes with this signature in the last month are on our good friend family 6 model 183 stepping 1, which is to say Intel Raptor Lake. (See also: bug 1893836, bug 1883761.) No other cpu-info has more than 6 crashes.

I'm never sure with this sort of bug whether it's better to close it or keep it open with low priority, but in this case the prospect of tracking back from the site of the crash to a hypothetical real bug seems nigh impossible even if I thought a bug existed, so I'm going to go ahead and mark it INVALID.