Bug 1895032 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
But `PORT_ArenaAlloc()` looks fallible.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return NULL.
Revision 1 by
on 
But `PORT_ArenaAlloc()` looks fallible.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return `NULL`. You can also emulate this by using the debugger to doctor `from->len` on line 254, then iterating that line. Eventually it returns `NULL`.
Revision 2 by
on 
But `PORT_ArenaAlloc()` looks fallible.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return `NULL`. You can also emulate this by using the debugger to doctor `from->len` to some large value on line 254, then iterating that line. Eventually it returns `NULL`.
Revision 3 by
on 
But `PORT_ArenaAlloc()` looks fallible.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return `NULL`. You can also emulate this by using the debugger to doctor `from->len` to some large value on line 254, then iterating that line. Eventually it returns `NULL`, rather than crashing with an OOM like `moz_xmalloc()`.
Revision 4 by
on 
But `PORT_ArenaAlloc()` is fallible, at least for large allocations and apparently for all allocations.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return `NULL`. You can also emulate this by using the debugger to doctor `from->len` to some large value on line 254, then iterating that line. Eventually it returns `NULL`, rather than crashing with an OOM like `moz_xmalloc()`.
Revision 5 by
on 
But `PORT_ArenaAlloc()` is fallible, at least for large allocations and apparently for all allocations.

`PORT_ArenaAlloc()` uses `PL_ARENA_ALLOCATE()`, which uses `PR_MALLOC()` if it can't just allocate from an arena. `PR_MALLOC()` uses `malloc()`, which calls `PageMalloc()`, which calls `MozJemalloc::malloc()`, which calls `BaseAllocator::malloc()`, which calls `arena_t::Malloc()`, which calls one of `arena_t::MallocSmall()`, `arena_t::MallocLarge()`, or `arena_t::MallocHuge()`, depending on the requested size. These all look fallible. Tracing `arena_t::MallocHuge()` eventually results in a call to the Windows API `VirtualAlloc()`. Faking its return value as NULL eventually causes `PORT_ArenaAlloc()` to return `NULL`. You can also emulate this by using the debugger to doctor `from->len` to some large value on line 254, then iterating that line. Eventually it returns `NULL`, rather than crashing with an OOM like `moz_xmalloc()`.

This path is similar to the one taken by fallible `nsTArray`, which uses `MozJemallocPHC::realloc()`, which calls `PageRealloc()`, which calls `BaseAllocator::realloc()`, which calls `arena_t::Ralloc()` or `arena_t::Malloc()`, the latter of which joins the flow above.

Back to Bug 1895032 Comment 8