[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2017 20:41:07 -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 11:01:48PM +0300, Tobias Koch wrote:
> >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.
> attached recorded via
>
> strace -o host-strace-qemu.log /usr/bin/qemu-arm-static -strace
> /usr/bin/ruby2.4 > qemu-strace-ruby.log 2>&1
>
> [...]
>
> 13641 set_tid_address(-159391760,-159706348,1,-159391412,-159391788,-150995520) = 13641
> 13641 open("/usr/etc/ld-musl-arm.path",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
> 13641 open("/usr/lib/libruby-2.4.so.2.4",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> 13641 fcntl64(3,F_SETFD,1) = 0
> 13641 fstat64(3,0xf6fff860) = 0
> 13641 read(3,0xf6fff460,936) = 936
> 13641 mmap2(NULL,2342912,PROT_EXEC|PROT_READ,MAP_PRIVATE,3,0) = 0xf650d000
> 13641 mmap2(0xf673e000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x221) = 0xf673e000
> 13641 mmap2(0xf6743000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0xf6743000
> 13641 close(3) = 0
> 13641 open("/usr/lib/libgmp.so.10",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> 13641 fcntl64(3,F_SETFD,1) = 0
> 13641 fstat64(3,0xf6fff860) = 0
> 13641 read(3,0xf6fff460,936) = 936
> 13641 mmap2(NULL,462848,PROT_EXEC|PROT_READ,MAP_PRIVATE,3,0) = 0xf649c000
> 13641 mmap2(0xf650b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x5f) = 0xf650b000
> 13641 close(3) = 0
> 13641 mprotect(0xf673e000,12288,PROT_READ) = 0
> 13641 mprotect(0xf650b000,4096,PROT_READ) = 0
> 13641 mprotect(0xf67fb000,4096,PROT_READ) = 0
> 13641 mprotect(0x00020000,4096,PROT_READ) = 0
> 13641 fstat64(0,0xf6fffd08) = 0
> 13641 fstat64(1,0xf6fffd08) = 0
> 13641 fstat64(2,0xf6fffd08) = 0
> 13641 mremap(-151003136,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-151007232,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-151011328,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> .
> .
> .
> 13641 mremap(4096,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(0,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-4096,4096,8192,0,0,-159391424) = -1 errno=14 (Bad address)
OK, qemu-user is just emulating mremap very poorly. The man page
documents that it fails with EFAULT when the address passed is not
valid, but qemu seems to be giving ENOMEM, which has a different
meaning. I remember we looked hard when this was first implemented to
find an acceptable/safe way to probe for valid pages, so I doubt we'll
find a better or equally good way that both works around the bug in
qemu-user and does the right thing on all real kernels. I think the
qemu bug should just be reported and fixed.
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.
