|
Message-ID: <20170621004107.GZ1627@brightrain.aerifal.cx> 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.