This is a follow up to r14682:
When an mmap retry is done without any constraints, the kernel can
place it into free or reservation segments (i.e. anywhere there is no
mapping yet).
In r14682 a sanity check made the hypothesis that the new mapping was
in a free segment, but it does not hold at least on Linux 3.12 and 3.16
on amd64 (tested under Debian).
There is no risk in allowing the mapping to end up in (what was
previously) a reservation at this point, because it is also allowed.
Patch by Guillaume Knispel <xilun0@gmail.com>. Fixes BZ #348269.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15538
Previously, whether the bitpattern was interpreted as a
signed or unsigned value depended on the platform.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15531
Ensure that no code is generated for client requests on x32.
From: Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15526
--pid:
i.e. debug output. Asserts originating from the address space
manager look exactly like that and we do not want to filter those
out by default.
Remove some specialised filter scripts that are no longer needed
and update a few .vgtest files accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15519
go wrong. As we can tell from the error messages what whent wrong
there is no need to have different exit codes to distinguish.
Spotted by Matthias Schwarzott.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15515
script and build prerequisites in tree. Suggested by Dimitry <dimhen@gmail.com>
Also add --disable-bootstrap and some verbiage as to how to speed
up the GCC build even further.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15509
At least on x86+gcc4.9, the test fails because step+finish
makes the program stop on the breakme call line (after the call)
instead of reaching line 120.
So; change the gdb commands so as to ensure we reach line 120
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15504
tc09_bad_unlock fails randomly for the following reason:
Thread 1 is creating a lock in a stack variable and locks it.
It then clones a Thread 2 that will unlock this lock.
The test fails if the Thread 2 unlocks the lock while the
main thread is still just after the clone syscall:
There is no unwind info in this area, and so doing a stacktrace
implies a nasty hack (see hg_main.c evh__pre_thread_ll_create).
There is no such hack when describing the address of the lock
(as there is no logic in the 'normal' stack trace to detect we are
in the clone syscall code).
In such a case, the unwind fail, and the lock address description
lacks the frame nr derived from the captured stack trace.
Adding --fair-sched=yes seems to make a more reproducible test.
Note that the proper solution to all these 'racy helgrind regtests'
would be to add some synchronisations operations between threads
that helgrind does not observe (e.g. using a technique similar to
the pipe big lock) and have correct (but invisible to helgrind) synchronisation
between the threads actions needed for a reproducible regtest.
Not very cheap to develop, --fair-sched=try is cheap and easy
so use that till someone courageous implements non visible synchronisation
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15497
