[PATCH v4] malloc: Improve malloc initialization
Florian Weimer
fweimer@redhat.com
Fri May 23 07:39:05 GMT 2025
* Tulio Magno Quites Machado Filho:
> Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
>
>> v4: Remove remaining uses of __malloc_initialized.
>>
>> Move malloc initialization to __libc_early_init. Use a hidden __ptmalloc_init
>> for initialization and a weak call to avoid pulling in the system malloc in a
>> static binary. All previous initialization checks can now be removed.
>>
>> Passes regress, OK for commit?
>
> I bisected crashes on 32-bit x86 to this commit.
> It's still unclear to me what is causing the issue, but one thing caught
> my attention: malloc() started to return addresses from mmap'ed areas
> while it used to return addresses from the software break for this
> particular program (dynamically linked llvm-objdump).
That part (the switch to mmap) I can explain. The order in
__libc_early_init is currently this:
/* Initialize system malloc. */
call_function_static_weak (__ptmalloc_init);
/* Initialize ctype data. */
__ctype_init ();
/* Only the outer namespace is marked as single-threaded. */
__libc_single_threaded = initial;
So __libc_single_threaded is false when __ptmalloc_init is called, and
we disable the use of brk.
> It looks like that even glibc memory allocations are not using the
> software break anymore (see the first lines calling brk() without a call
> from the other libraries).
Still the switch to mmap is not supposed to result in crashes. This
could point to a completely different bug. What is the nature of the
crashes?
Thanks,
Florian
More information about the Libc-alpha
mailing list