Public bug reported:
Currently when executing a linux-user target, mmap.c is in use- the
model it uses internally for figuring out what the mmap address actually
should be basically is an accumulator, every mmap invocation (regardless
of munmap's that cleared the previous usage) is center on the n
** Attachment added:
"0001-try-to-reuse-recently-freed-mmap-space-to-reduce-gue.patch"
https://bugs.launchpad.net/bugs/682326/+attachment/1747588/+files/0001-try-to-reuse-recently-freed-mmap-space-to-reduce-gue.patch
--
linux-user/mmap exhaustion
https://bugs.launchpad.net/bugs/682326
You r
Additional note... it *looks* like the deadlock potential is there
already in 0.13, it's just heavily exacerbated by this patch- out of
about 600 builds I've seen 2 lockup in the same fashion (rate was far
higher with the patch on this ticket).
--
qemu-arm segfaults executing msgmerge (gettext)
h
@Peter, that patch, against 0.13 results in some odd deadlocks;
specifically a racey deadlock during signal handling best I can tell.
Attached is an strac'ing of the make process- nothing special, just
forking off some children, wait'ing on the results- if you look earlier
in the log you'll see th
Pardon, badly phrased on my part- basically we can get either -1 or old.
If we changed that conditional w/in arm-semi.c to:
if (-1 != limit && limit != ts->heap_base) {
that should do the trick in a cross platform way, although we'll have to
tweak the for loop to handle when limit degrades to 0.
Look through linux-user/syscall.c; looks like the flaw is more in do_brk
itself. Invocations of do_brk *appear* to all assume that it's
basically brk like in it's behaviour- -1 on failure, else a non-negative
value of what the size now is. So... your patch is breaking away from
proper behaviour,
