From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: r yang <decatf@gmail.com>
Subject: Re: Infinite loop in malloc
Date: Fri, 25 Jan 2019 20:30:14 -0500 [thread overview]
Message-ID: <20190126013014.GX23599@brightrain.aerifal.cx> (raw)
In-Reply-To: <20190125231136.GX21289@port70.net>
On Sat, Jan 26, 2019 at 12:11:37AM +0100, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2019-01-25 23:28:32 +0100]:
> > * r yang <decatf@gmail.com> [2019-01-25 10:13:50 -0500]:
> > > pmbootstrap is a development environment to build/install postmarketOS
> > > (based on Alpine Linux) for Android devices. One of the things it does
> > > is use qemu static to emulate an ARM based Alpine Linux chroot
> > > environment.
> > >
> > > There is a bug while compiling certain packages in the qemu ARM chroot.
> > > The qemu process can get stuck in an infinite loop when calling malloc.
> > >
> > > pmbootstrap uses Alpine Linux edge repositories. It's using the current
> > > musl package version 1.1.20.
> > >
> > > Here is a gdb backtrace.
> > > #0 malloc (n=<optimized out>, n@entry=9) at src/malloc/malloc.c:320
> > > #1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@entry=9) at gmem.c:99
> > > #2 0x000000006018bcab in g_strdup (str=<optimized out>, str@entry=0x60200abf "call_rcu") at gstrfuncs.c:363
> > > #3 0x000000006016e31d in qemu_thread_create (thread=thread@entry=0x7ffe89fb1a10, name=name@entry=0x60200abf "call_rcu",
> > > start_routine=start_routine@entry=0x60174c00 <call_rcu_thread>, arg=arg@entry=0x0, mode=mode@entry=1) at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526
> > > #4 0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327
> > > #5 0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26
> > > #6 0x00000000601be8db in fork () at src/process/fork.c:33
>
> it seems the issue is simply that qemu-arm-static is a multi-threaded
> process and here it forks and calls malloc in the fork handler of
> the child process.
>
> it's easy to imagine that if fork runs concurrently with a free
> the malloc state remains corrupted in the child hence the malloc
> fails there.
>
> i'm not sure if musl can detect or fix this up easily.
In that case it's undefined behavior by qemu. After a multithreaded
process forks, the child process is permanently in an async signal
context. Calling malloc or any other AS-unsafe function is undefined.
Without knowing what qemu is trying to do, it's not clear how fixable
this might be.
Rich
next prev parent reply other threads:[~2019-01-26 1:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-25 15:13 r yang
2019-01-25 21:49 ` Markus Wichmann
2019-01-25 21:57 ` Szabolcs Nagy
2019-01-25 21:55 ` Markus Wichmann
2019-01-25 22:28 ` Szabolcs Nagy
2019-01-25 23:11 ` Szabolcs Nagy
2019-01-26 1:30 ` Rich Felker [this message]
2019-01-26 13:59 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190126013014.GX23599@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=decatf@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).