realloc(NULL, 0) returned NULL without allocating anything, while malloc(0) returns a unique pointer. C11 7.22.3.5p3 says realloc with a null pointer behaves like malloc for the specified size, so code that grows an empty buffer from zero elements (p = realloc(p, n * size) with n == 0) and treats NULL as out of memory failed on its first call.
FreeBSD 11.4 never returns NULL from realloc for a zero size; je_realloc rounds the size up before choosing between resizing and allocating (contrib/jemalloc/src/jemalloc.c, je_realloc).
A null pointer with size 0 now reaches the allocator's realloc, which allocates as malloc(0) does. A non-null pointer with size 0 is still freed and NULL returned, as before.
Co-authored-by: milescoviello <kitslayer29@gmail.com>
Two catalog titles stop on the absent libSceLibcInternal export reallocf
(YMZO9ChZb0E) on main 0f863c10:
- PPSA97510 PSXS5 2.2.0
- PPSA98510 SwanStationPS5 1.1.3
FAIL: unresolved ELF import YMZO9ChZb0E from libSceLibcInternal.prx
reallocf follows FreeBSD 11 lib/libc/stdlib/reallocf.c (freebsd-src
stable/11 5ed7eb0d97ba4436218e810f61bd059acba984c2) on top of the guest
realloc: it reallocates through the application heap, and when realloc
fails (the application allocator returns null or the default heap
rejects the size) it frees the block through the same allocator, sets
ENOMEM and returns null. Size 0 frees and returns null as realloc does
here, so the block is not freed twice. Other heap failures throw, as
for realloc. The NID matches tools/nid_names.py and aerolib.
The application heap tests cover grow, shrink, a null pointer, size 0
and failure with both the replacement and the default allocator.
Co-Authored-By: screamm <noreply@github.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
getcwd(NULL, size) returned memory from the guest heap directly, while
the caller frees it with free(), which goes to the application heap.
With a title's malloc replacement registered, that free reached the
replacement with a pointer it never returned. Allocate from the
application heap like strdup, and report ENOMEM when it returns null.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PPSA16064 (Minecraft Dungeons II) ships its own libc.prx, which imports
two C++ runtime symbols from libSceLibcInternal that no host library
exported, so the title failed to load:
- std::__sce_v2::_Xbad_function_call() (_ZNSt8__sce_v219_Xbad_function_callEv),
the inline-namespace spelling of the existing std::_Xbad_function_call.
It throws std::bad_function_call the same way.
- operator delete(void*, std::size_t, std::align_val_t)
(_ZdlPvmSt11align_val_t), the sized form of the existing aligned
delete. It frees the pointer the same way and ignores the size.
application_heap_default frees an aligned block through the sized form
and checks that a null pointer frees nothing. exception_runtime checks
that the new thrower throws a standard exception; it is built only on
Linux and was not run here (Windows 11, MinGW GCC 15.2).
The finalizer was registered with std::atexit from the heap handshake, which
runs after libc's own __cxa_atexit runner and the title's exit callbacks
register theirs. std::atexit runs handlers in reverse registration order, so
the heap was torn down first: an exit user that allocated then threw
"application heap: allocator has been finalized" out of a destructor path,
which terminates the process.
Register the finalizer from a namespace-scope object instead, so it is
registered when libc is loaded and therefore runs last, and make finalize()
idempotent rather than throwing on a second pass.
application_heap_exit_order registers a guest exit callback that allocates
through the heap and aborts with "application heap: allocator has been
finalized" on the previous code.
SceLibcMallocReplace lists calloc before realloc (malloc, free, calloc,
realloc, memalign, reallocalign, posix_memalign, ...), as the table in
retail titles shows. realloc therefore called the application's calloc
with the old pointer as the element count, and calloc called realloc.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>