Created attachment 460800 [details] Testcase Found by Igalia Fuzzing Campaign. The attached test case fails with the following message: SHOULD NEVER BE REACHED WebKit//Source/JavaScriptCore/heap/LocalAllocator.cpp(148) : void* JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
<rdar://problem/96847395>
Mikhail, I'm not able to reproduce this on a Release or Debug build of https://commits.webkit.org/252364@main running on M1. What code version did you build? What type of build? What port? What machine did you test on? Thanks.
Assuming ToT code, LocalAllocator.cpp:148 is: ``` MarkedBlock::Handle* block = m_directory->tryAllocateBlock(heap); if (!block) { if (failureMode == AllocationFailureMode::Assert) RELEASE_ASSERT_NOT_REACHED(); // <---- line 148 else return nullptr; } ```
Hey Mark, I just double-checked in an ARMv8l linux machine and I was able to reproduce it using WebKit from commit e94f950ce43b. Maybe it's a linux only crash?
I'll also upload the original test case found by the fuzzer.
Created attachment 460825 [details] Original testcase found by the fuzzer
I couldn't reproduce it on our ARM64 linux box anymore... I'm not sure how our ARM64 fuzzer found it...
From the site of the crash, we know that this is an OOM issue.
I see, probably it was triggered because our fuzzer runs 32 tests in parallel and we set no memory limit to them. Maybe there was a memory-hungry test running in parallel. So, is it a bug? Or is it just the error message that needs to be improved?
(In reply to Mikhail R. Gadelha from comment #9) > I see, probably it was triggered because our fuzzer runs 32 tests in > parallel and we set no memory limit to them. Maybe there was a memory-hungry > test running in parallel. > > So, is it a bug? Or is it just the error message that needs to be improved? It's not a bug. One option is to make it not crash on failure to allocate. That would mean having the caller not pass in AllocationFailureMode::Assert. Since we don't have a crash stack trace, and can't reproduce the issue, I'm not sure we can do anything about this. This is also not a security issue. It's an ordering shut down due to resource exhaustion. At best, it's a fuzzer blocker.
(In reply to Mark Lam from comment #10) > One option is to make it not crash on failure to allocate. By this, I mean make the caller check for the allocator returning nullptr, and throwing an OOME. This may or may not be easy to do depending on who the callers are.
If this is not blocking the fuzzer, we can resolve this as WONTFIX.
Closing it as WONTFIX is fine. I'll add a rule to filter out these cases, we already do it for other OOM tests.