Closed Bug 1818621 Opened 3 years ago Closed 3 years ago

Crash in [@ WarpCacheIRTranspiler::getOperand]

Categories

(Core :: JavaScript Engine: JIT, defect)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: mccr8, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/8cbb0a8b-4929-49c3-9e76-92de10230223

Reason: SIGSEGV / SI_KERNEL

Top 10 frames of crashing thread:

0  libxul.so  WarpCacheIRTranspiler::getOperand const  js/src/jit/WarpCacheIRTranspiler.cpp:123
0  libxul.so  WarpCacheIRTranspiler::emitGuardNullProto  js/src/jit/WarpCacheIRTranspiler.cpp:440
1  libxul.so  WarpCacheIRTranspiler::emitGuardNullProto  js/src/jit/WarpCacheIRTranspiler.cpp:293
1  libxul.so  WarpCacheIRTranspiler::transpile  js/src/jit/WarpCacheIRTranspiler.cpp:325
2  libxul.so  js::jit::TranspileCacheIRToMIR  js/src/jit/WarpCacheIRTranspiler.cpp:5545
2  libxul.so  js::jit::WarpBuilder::buildIC  js/src/jit/WarpBuilder.cpp:3176
3  libxul.so  js::jit::WarpBuilder::buildBody  js/src/vm/SharedStencil.h
4  libxul.so  js::jit::WarpBuilder::build  js/src/jit/WarpBuilder.cpp:294
5  libxul.so  js::jit::CompileBackEnd  js/src/jit/Ion.cpp:1528
6  libxul.so  js::jit::IonCompileTask::runTask  js/src/jit/IonCompileTask.cpp:52

Not a ton of crashes here, but it seems like one person is crashing a bit. The comment in the crash is "1099 pdf crashes tab" and the URL looks like a tax related document stored on their local disk. All on the 20230222214030 Nightly.

Took a look at the crash dump. The disassembled binary crashes here:

    7f3629b42f50:	44 0f b7 f6          	movzwl %si,%r14d
    7f3629b42f54:	48 8b 7f 10          	mov    0x10(%rdi),%rdi
    7f3629b42f58:	49 8b 47 40          	mov    0x40(%r15),%rax
    7f3629b42f5c:	4a cb                	rex.WX lretq 
^^^^^^^^^^^^^^^^^	^^^^^^^^^^^^^^^^^^^^^	^^^^^^^^^^^^^^
    7f3629b42f5e:	1c f0                	sbb    $0xf0,%al

Note that A) the lretq and the sbb are nonsense, and B) flipping a single bit (cb -> 8b) gets us 4a 8b 1c f0, which disassembles to mov 0x0(%rax, %r14, 8), %rbx (a very plausible instruction in context, given that we've just set rax and r14).

It looks like some poor unfortunate soul had a bit flip in their binary, which crashes whenever they reach this code. There's no bug here, just a cosmic ray or bad hardware.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.