[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