[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190126013014.GX23599@brightrain.aerifal.cx>
Date: Fri, 25 Jan 2019 20:30:14 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: r yang <decatf@...il.com>
Subject: Re: Infinite loop in malloc
On Sat, Jan 26, 2019 at 12:11:37AM +0100, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2019-01-25 23:28:32 +0100]:
> > * r yang <decatf@...il.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@...ry=9) at src/malloc/malloc.c:320
> > > #1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@...ry=9) at gmem.c:99
> > > #2 0x000000006018bcab in g_strdup (str=<optimized out>, str@...ry=0x60200abf "call_rcu") at gstrfuncs.c:363
> > > #3 0x000000006016e31d in qemu_thread_create (thread=thread@...ry=0x7ffe89fb1a10, name=name@...ry=0x60200abf "call_rcu",
> > > start_routine=start_routine@...ry=0x60174c00 <call_rcu_thread>, arg=arg@...ry=0x0, mode=mode@...ry=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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
