MOZ_CRASH() at src/js/src/jit/arm64/vixl/MacroAssembler-vixl.cpp:2030
Categories
(Core :: JavaScript Engine: JIT, defect, P1)
Tracking
()
People
(Reporter: sm-bugs, Assigned: nbp)
References
(Blocks 2 open bugs)
Details
(Keywords: crash, reporter-external, testcase)
Attachments
(2 files)
Steps to reproduce:
Platform: aarch64
Version: 22a0993169acd84ab8d574fefddcb4da04b77c91
Args: js --fuzzing-safe <test-case>
Test case:
const v3 = Array(65535);
function* f4() {
return f4;
}
const v7 = f4.constructor.apply(null, v3);
const t5 = v7().return(Uint16Array).value;
const v11 = new t5(v7);
v11.filter(v7);
Actual results:
MOZ_CRASH() at src/js/src/jit/arm64/vixl/MacroAssembler-vixl.cpp:2030
#0 0xaaaaca392c90 in vixl::UseScratchRegisterScope::AcquireNextAvailable(vixl::CPURegList*) jit/arm64/vixl/MacroAssembler-vixl.cpp:2030:3
#1 0xaaaaca383028 in vixl::UseScratchRegisterScope::AcquireSameSizeAs(vixl::Register const&) jit/arm64/vixl/MacroAssembler-vixl.cpp:1913:14
#2 0xaaaaca38dab4 in vixl::MacroAssembler::LoadStoreMacro(vixl::CPURegister const&, vixl::MemOperand const&, vixl::LoadStoreOp) jit/arm64/vixl/MacroAssembler-vixl.cpp:1221:27
#3 0xaaaaca2e9c68 in js::jit::MoveEmitterARM64::emitGeneralMove(js::jit::MoveOperand const&, js::jit::MoveOperand const&) jit/arm64/MoveEmitter-arm64.cpp
#4 0xaaaaca2d7a0c in js::jit::MoveEmitterARM64::emit(js::jit::MoveResolver const&) jit/arm64/MoveEmitter-arm64.cpp:37:5
#5 0xaaaaca57dd8c in js::jit::CodeGenerator::visitMoveGroup(js::jit::LMoveGroup*) jit/CodeGenerator.cpp:4220:11
#6 0xaaaaca5adc38 in js::jit::CodeGenerator::generateBody() jit/CodeGenerator.cpp:8084:9
#7 0xaaaaca644874 in js::jit::CodeGenerator::generate(js::jit::WarpSnapshot const*) jit/CodeGenerator.cpp:16634:8
#8 0xaaaaca7027f4 in js::jit::GenerateCode(js::jit::MIRGenerator*, js::jit::LIRGraph*, js::jit::WarpSnapshot const*) jit/Ion.cpp:1587:17
#9 0xaaaaca7027f4 in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) jit/Ion.cpp:1617:28
#10 0xaaaaca73b7d0 in js::jit::IonCompileTask::runTask() jit/IonCompileTask.cpp:52:24
#11 0xaaaaca73b7d0 in js::jit::IonCompileTask::runHelperThreadTask(js::AutoLockHelperThreadState&) jit/IonCompileTask.cpp:30:5
#12 0xaaaac9362134 in js::GlobalHelperThreadState::runTaskLocked(JS::HelperThreadTask*, js::AutoLockHelperThreadState&) vm/HelperThreads.cpp:650:11
#13 0xaaaac9361fcc in js::GlobalHelperThreadState::runOneTask(JS::HelperThreadTask*, js::AutoLockHelperThreadState&) vm/HelperThreads.cpp:606:3
#14 0xaaaac93a7ce8 in js::HelperThread::threadLoop(js::InternalThreadPool*) vm/InternalThreadPool.cpp:324:25
#15 0xaaaac93a785c in js::HelperThread::ThreadMain(js::InternalThreadPool*, js::HelperThread*) vm/InternalThreadPool.cpp:251:11
#16 0xaaaac93d22c4 in void js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::callMain<0ul, 1ul>(std::integer_sequence<unsigned long, 0ul, 1ul>) threading/Thread.h:228:5
#17 0xaaaac93d22c4 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start(void*) threading/Thread.h:217:11
#18 0xffff80004b2c in start_thread nptl/pthread_create.c:447:8
#19 0xffff8006d888 in thread_start misc/../sysdeps/unix/sysv/linux/aarch64/clone3.S:76
Updated•1 month ago
|
Updated•1 month ago
|
Assignee | ||
Comment 1•1 month ago
|
||
I will look into it this week.
Assignee | ||
Comment 2•1 month ago
|
||
The problem might be related to recent Register Allocator changes, which now seems to emit absolute memory to absolute memory moves, which trip over the vixl assertion as we no longer have any temporary register available to resolve the immediate memory.
Comment 3•1 month ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #2)
The problem might be related to recent Register Allocator changes, which now seems to emit absolute memory to absolute memory moves,
As far as I know the recent register allocator changes shouldn't have added a new kind of move. They were mainly compile time optimizations with either exactly the same allocation results or slightly different allocations when there were multiple valid answers, but no completely new capabilities.
Assignee | ||
Comment 4•1 month ago
|
||
Assignee | ||
Comment 5•1 month ago
|
||
The patch from comment 4 is a band-aid which works around the initial issue. It might be worth landing first as while it hints as having a problem where we are lacking a register, it does not provide any hint on where.
Updated•1 month ago
|
Assignee | ||
Comment 6•29 days ago
|
||
I can still reproduce this bug with builds from 2021, so I guess this is not the recent Register Allocator modifications.
Comment 7•24 days ago
|
||
This looks like the VIXL_CHECK() will always crash the build safely in this situation, even in Release? Could be annoying but hard to see how to exploit it. Or are we misunderstanding these checks?
Assignee | ||
Comment 8•22 days ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #7)
This looks like the VIXL_CHECK() will always crash the build safely in this situation, even in Release? Could be annoying but hard to see how to exploit it. Or are we misunderstanding these checks?
This is correct, I do not think this assertion can be exploited.
Updated•17 days ago
|
Updated•16 days ago
|
Assignee | ||
Comment 9•9 days ago
|
||
Description
•