[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170615141927.GN1627@brightrain.aerifal.cx>
Date: Thu, 15 Jun 2017 10:19:27 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np doing loads of mremaps on ARM, MIPS
under QEMU user-mode
On Thu, Jun 15, 2017 at 04:08:03PM +0300, Tobias Koch wrote:
> Hi,
>
> running under QEMU user mode, Ruby 2.4 (and it seems also Guile) ARM
> and MIPS binaries take a long time to start and eventually crash.
> The long startup seems to come from this loop
>
> while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE,
> 0)==MAP_FAILED && errno==ENOMEM)
> l += PAGE_SIZE;
>
> being executed hundreds of times in pthread_getattr_np. Any idea
> what this could be about except from maybe being a QEMU bug?
This is not particularly unusual (it's the best way we could find to
measure the initial thread's stack size), but it's possible that qemu
user mode is botching emulation of mremap and thus resulting in a
wrong stack size being reported. Can you send a full strace (qemu-arm
-strace, maybe also real strace of the qemu process with the host
strace utility) log of the crash? That will probably shed some light
on what's happening.
> The subsequent crash then occurs after memory set aside by alloca is
> accessed. I think this may be unrelated.
It seems plausible that it's related or that it's unrelated.
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.
