Here's why:
The condition
if (VG_(brk_limit) > VG_(brk_base)) line 1223
is reachable iff
newbrk < VG_(brk_base) on line 1201 is false AND
newbrk < VG_(brk_limit) on line 1205 is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk < VG_(brk_limit) is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk <= VG_(brk_limit) - 1 is true
Combine
VG_(brk_base) <= newbrk <= VG_(brk_limit) - 1
Therefore
VG_(brk_base) <= VG_(brk_limit) - 1
Or
VG_(brk_base) < VG_(brk_limit)
Which is the same as
VG_(brk_limit) > VG_(brk_base)
qed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15181
Mark 2 additional syscalls as 'mayblock' when fuse-compatible hint
is given.
Patch from aozgovde@ralota.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15112
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
The function is used in VG_(client_syscall) to avoid extending the stack
when it is clear that the current value of the stack pointer does not
point into a segment that looks like a stack segment.
See the comments in the code there.
As a side effect of this we can now revert r15018 which increased
the stack size of the alternate stack in memcheck/tests/sigaltstack.c.
The reason is that the belief at the time: "alternate stack is too small"
was not correct. What instead happened was that VG_(client_syscall) called
VG_(extend_stack) without need (the syscall was tgkill) and the new stack
pointer happened to be in a file segment.
In other words: the current stack pointer was still within the alternate
stack, i.e. the alternate stack was (barely) large enough.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15034
We often get bug reports for an unhandled system call which don't
make it clear what platform is in use, which makes it impossible
to know which system call it is.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15033
bz#344560
- Also fixes memcheck/tests/badpoll test on OS X
- Problem occurs because the guest stack seen in a system call pre or post
function happens to not have a correct topmost stack frame, as Darwin system
call stubs do not start with the usual function prolog.
- New regression test case added.
- Thanks to Greg Banks for research, patch and test case.
Before:
== 587 tests, 240 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
After:
== 588 tests, 239 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14985
- remove redundant asserts
- let VG_(am_extend_into_adjacent_reservation_client) worry about
- whether delta is too large
- whether the segment abutting this one exists and is a reservation
segment
The function already checks these things. No need to do it again here.
- do_brk does not need to know that a reservation segment must not
shrink beyond a single page. That detail ought to be hidden in
the address space manager.
Also, turn a few conditions into asserts.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14967
Some architectures, e.g. s390, don't have dedicated recvmmsg and sendmmsg
system calls, but use the socketcall multiplexing system call with
SYS_RECVMMSG or SYS_SENDMMSG (just like the accept4 systemcall can also
be called through socketcall). Create separate helpers for recvmmsg and
sendmmsg helpers that can be used by either the direct syscall or the
socket call.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14964
- Tighten up on asserts
- Simplify; as the function grows memory into a free segment, there
cannot possibly be any translations to be discarded. Free segments
do not have translations. sane_NSegment will make sure.
- Change the prototype to take in the start address of the mapping and
return a pointer to the resized segment. Previously, the code
ok = VG_(am_extend_map_client)( &d, old_seg, needL );
if (!ok)
goto eNOMEM;
VG_TRACK( new_mem_mmap, needA, needL,
old_seg->hasR, old_seg->hasW, old_seg->hasX,
was examining old_seg->hasR etc even though VG_(am_extend_map_client)
stated that *old_seg was invalid after the function returned.
That wasn't exactly a problem, but clearly looked wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14963
ppc64 might fall back to socketcall in some cases, but arm64 always uses
accept4 syscall directly. Some (confusing) background on when/how glibc
(wrongly) decides to use a direct accept4 or the socketcall system call:
https://sourceware.org/ml/libc-alpha/2013-12/msg00014.html
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14926
