Bug 309638 – [libpas] SIGSEGV at 0x0 in pas_page_header_table_add when utility heap is exhausted on ARM64 release

• Status: RESOLVED
• Resolution: FIXED
• Component: bmalloc

[Sosuke Suzuki]

Created attachment 478625 [details]
reproduction

On macOS ARM64 release builds, PAS_ENABLE_ASSERT is 0 (pas_config.h:74),
so PAS_ASSERT is a no-op.

pas_utility_heap_allocate_with_alignment() can silently return NULL when
the utility heap is exhausted. pas_page_header_table_add() then computes:

  page_base = (pas_page_base*)((void**)NULL + 2);  // = 0x10
  *get_boundary_ptr(..., 0x10) = boundary;          // get_boundary_ptr returns NULL → write to 0x0

---

stack trace:

  * thread #1, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    * frame #0: JavaScriptCore`pas_segregated_exclusive_view_create(directory=0x00000001094fe100, index=321137) at pas_segregated_exclusive_view.c:59
      frame #1: JavaScriptCore`take_first_eligible_direct_create_new_view_callback at pas_segregated_size_directory.c:547 [inlined]
      frame #2: JavaScriptCore`pas_segregated_size_directory_take_first_eligible_impl at pas_segregated_size_directory_inlines.h:210
      frame #3: JavaScriptCore`pas_segregated_size_directory_take_first_eligible at pas_segregated_size_directory.c:586
      frame #4: JavaScriptCore`pas_local_allocator_refill_with_known_config at pas_local_allocator_inlines.h:1148 [inlined]
      frame #5: JavaScriptCore`pas_local_allocator_try_allocate_small_segregated_slow_impl at pas_local_allocator_inlines.h:1609 [inlined]
      frame #6: JavaScriptCore`pas_local_allocator_try_allocate_small_segregated_slow at pas_local_allocator_inlines.h:1631 [inlined]
      frame #7: JavaScriptCore`bmalloc_heap_config_specialized_local_allocator_try_allocate_small_segregated_slow at bmalloc_heap_config.c:43
      frame #8: JavaScriptCore`bmalloc_try_allocate_inline at bmalloc_heap_inlines.h:279 [inlined]
      frame #9: JavaScriptCore`bmalloc::api::tryMalloc at bmalloc.h:67 [inlined]
      frame #10: JavaScriptCore`WTF::tryFastCompactMalloc at FastMalloc.cpp:569
      frame #11: JavaScriptCore`WTF::FastCompactMalloc::tryMalloc at FastMalloc.h:286 [inlined]
      frame #12: JavaScriptCore`WTF::StringImpl::tryCreateUninitialized<unsigned char> at StringImpl.h:1097 [inlined]
      frame #13: JavaScriptCore`JSC::repeatCharacter<unsigned char>(globalObject, character='x', repeatCount=384) at JSStringInlines.h:253
      frame #14: JavaScriptCore`JSC::stringProtoFuncRepeat(globalObject, callFrame) at StringPrototype.cpp:2006
      frame #15: (JIT frame)

[Yusuke Suzuki]

So, this is effectively OOM. Crash is expected, but question is we should make it more explicit assert for nullptr from utility heap allocation.

[Sosuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/60353

[EWS]

Committed 309075@main (ddcb0827a4e5): <https://commits.webkit.org/309075@main>

Reviewed commits have been landed. Closing PR #60353 and removing active labels.

[Ryan Haddad]

rdar://172303494