qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] ARM brk bug


From: malc
Subject: Re: [Qemu-devel] ARM brk bug
Date: Sun, 4 Mar 2012 01:23:09 +0400 (MSK)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Sat, 3 Mar 2012, Alexander Graf wrote:

> 
> On 02.03.2012, at 18:49, Peter Maydell wrote:
> 
> > On 27 February 2012 15:16, Bernhard M. Wiedemann <address@hidden> wrote:
> >> I found that running a debian arm5 bash with qemu runs into varying
> >> problems with -R but works without.
> > 
> > So I had a look at this this afternoon, and what seems to be happening
> > is that with -R, the call to target_mmap() in elfload.c:setup_arg_pages()
> > (which creates the stack) is putting the stack immediately after the
> > bash BSS segment in the address space. This means that brk() will
> > never be able to expand, and it looks like something in either bash
> > or libc's locale code isn't correctly handling the failure, so we
> > crash. (The segfault is from a strlen(NULL) from setlocale() I think.)
> > 
> > We should probably try to put the stack somewhere more sensible than
> > where it currently ends up...
> 
> I wrote a small test case to reproduce the breakage as far as I understood it 
> at least:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/fcntl.h>
> 
> int main(int argc, char **argv)
> {
>     void *curbrk;
>     void *tmp;
>     char buf[1024];
>     int fd, r;
> 
>     tmp = mmap((void*)0x5000UL, 0x10000, PROT_READ|PROT_WRITE,
>                MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

You are setting a bad example here (not that i know if that makes a
dent of a practical difference in this case): passing 0 as an fd even
in MAP_ANONYMOUS case is unsafe.

[..snip..]

-- 
mailto:address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]