mirror of
https://github.com/jemalloc/jemalloc.git
synced 2026-07-08 14:57:21 +03:00
7ce8b9165d
free_sized() and free_aligned_sized() forward straight to sdallocx(), which expects a non-NULL pointer and asserts on it in debug builds. C23 says both should accept NULL and do nothing, like free(NULL) does, so a NULL argument either trips that assert or feeds NULL into the dealloc path in release builds. It is not hard to hit. glibc 2.41 ships free_sized()/free_aligned_sized(), and a C++ sized delete of a null pointer compiles down to a free_sized() call. Once jemalloc is preloaded its versions take over, and that NULL call takes down the process. I ran into it with GTK4/GLib apps under LD_PRELOAD. Check for NULL first, the way free() already does, and add an integration test covering the NULL case for both functions. While here, give free_aligned_sized() its own core.free_aligned_sized.entry and .exit logging and call je_sdallocx_impl() directly rather than the je_sdallocx() wrapper, so it mirrors free_sized() and no longer logs under sdallocx. The C++ sized-delete paths (sizedDeleteImpl, alignedSizedDeleteImpl) get the same treatment: log entry/exit unconditionally and guard the call with likely(ptr != nullptr). |
||
|---|---|---|
| .. | ||
| cpp | ||
| aligned_alloc.c | ||
| allocated.c | ||
| extent.c | ||
| extent.sh | ||
| free_sized.c | ||
| malloc.c | ||
| mallocx.c | ||
| mallocx.sh | ||
| MALLOCX_ARENA.c | ||
| overflow.c | ||
| posix_memalign.c | ||
| rallocx.c | ||
| sdallocx.c | ||
| slab_sizes.c | ||
| slab_sizes.sh | ||
| smallocx.c | ||
| smallocx.sh | ||
| thread_arena.c | ||
| thread_tcache_enabled.c | ||
| xallocx.c | ||
| xallocx.sh | ||