Bug 242612 – [AArch32] SHOULD NEVER BE REACHED in void* JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)

• Component: JavaScriptCore
• Status: RESOLVED WONTFIX

[Mikhail R. Gadelha]

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)

[Radar WebKit Bug Importer]

<rdar://problem/96847395>

[Mark Lam]

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.

[Mark Lam]

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;
    }
```

[Mikhail R. Gadelha]

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?

[Mikhail R. Gadelha]

I'll also upload the original test case found by the fuzzer.

[Mikhail R. Gadelha]

Created attachment 460825 [details]
Original testcase found by the fuzzer

[Mikhail R. Gadelha]

I couldn't reproduce it on our ARM64 linux box anymore... I'm not sure how our ARM64 fuzzer found it...

[Mark Lam]

From the site of the crash, we know that this is an OOM issue.

[Mikhail R. Gadelha]

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?

[Mark Lam]

(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.

[Mark Lam]

(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.

[Mark Lam]

If this is not blocking the fuzzer, we can resolve this as WONTFIX.

[Mikhail R. Gadelha]

Closing it as WONTFIX is fine. I'll add a rule to filter out these cases, we already do it for other OOM tests.