bz#344621
- Unnamed semaphores are not supported on OS X, must use named semaphores.
- To use named semaphores sem_open() instead of sem_init() utilised.
- Test case updated accordingly across all platforms.
Before:
== 586 tests, 240 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
After:
== 586 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@14968
- 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
Iop_RecipStep64Fx2, Iop_RSqrtStep64Fx2
Iop_RSqrtEst64Fx2, Iop_RecipEst64Fx2
Iop_RecpExpF64, Iop_RecpExpF32
--This line, and those below, will be ignored--
M memcheck/mc_translate.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14959
In addition raise the minimal Linux version to 2.6 as there is almost
no test coverage for 2.4 and 2.6 was released in 2003.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14955
and VG_(am_get_segment_starts) to indicate which segments
should be collected. That should solve the following problem:
in m_main.c we used to:
seg_starts = VG_(get_segment_starts)( &n_seg_starts );
for (i = 0; i < n_seg_starts; i++) {
Word j, n;
NSegment const* seg
= VG_(am_find_nsegment)( seg_starts[i] );
vg_assert(seg);
if (seg->kind == SkFileC || seg->kind == SkAnonC) {
...
// ... dynamic memory allocation for valgrind
...
}
This caused the vassert(seg) to fire because the dynamic memory
allocation further down the loop changed segments such that a
valgrind segment which used to be non-SkFree suddenly became
SkFree and hence VG_(am_find_nsegment) returned NULL. Whoom.
With this revision we only collect the segments we're really
interested in. For the example above that is all client segments.
So if V allocates memory -- fine. That will not change the layout
of client segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14949
loop forever. In particular, it will do that when two symbols have
exactly the same address range but differ in their .isText attribute.
Fixes#342117.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14948
Escape newlines in command arguments for "cmd:" header field in dumps
We could do unescaping in callgrind_annotate, but a escaped command
even seems better there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14947
to help with MSVC2013 compiled code. Variant of a patch from
Mark Browning (mabrowningrr@gmail.com). Fixes#211529.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14942
output from /usr/bin/strings, so as to not get confused by substrings
".pdb" and ".PDB" when they don't appear at the end of a line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14938
Likewise for VG_(am_next_nsegment). Also make the code similar to
VG_(am_find_nsegment) for easier comprehension.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14937
and rename VG_(am_set_segment_hasT_if_SkFileC_or_SkAnonC) to
VG_(am_set_segment_hasT_if_client_segment). Change it so it handles
all client segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14936
(1) It is always invalid for the incoming segment pointer to be
out of range. Assert that.
(2) Let the compiler do the address arithmetic. They're good at that
and therefore:
(3) No asserts needed to check the result.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14933
trash list. Not doing so was causing r12 to get corrupted by the
called function, which lead to some very strange failures in Helgrind
on arm32. Fixes#344033.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14929
confusing SP and LR and resulting in no backtraces during internal
assertion failures etc on this platform. Fixes#343219. Noticed by
dimitry@google.com.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14928
in the inline assembly, because gcc doesn't like that when compiling
for Thumb. And this file is compiled for Thumb during "make check".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14927
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
