Convert from dos to unix text files:
./none/tests/amd64-linux/cet_nops_fs.c
./none/tests/amd64-linux/cet_nops_gs.c
./none/tests/mips32/mips32_dspr2.c
./none/tests/mips32/mips32_dsp.c
On various systems none/tests/amd64-linux/map_32bits.vgtest fails with:
first mmap: Cannot allocate memory.
The problem is that the --aspace-minaddr is too tight. Newer glibc seem
to mmap some memory and so even our first mmap with MMAP_32BIT will fail.
The solution is to make a bit more memory < 2GB available.
If there is 16MB available the test always seems to succeed without
needing too many tries. The original 256K is too low.
https://bugs.kde.org/show_bug.cgi?id=406422
into three different files with regards to using
fs prefix, gs prefix or no fs/gs prefix.
Pertains to BZ#379525.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16421
--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
324181 was previously closed with a solution to always make
MAP_32BIT fail. This is technically correct/according to the doc,
but is not very usable.
This patch ensures that MAP_32BIT mmap is succesful, as long as
aspacemgr gives a range in the first 2GB
(so, compared to a native run, MAP_32BIT will fail much more quickly
as aspacemgr does not reserve the address space below 2GB on a 64 bits).
Far to be perfect, but this is better than nothing.
Added a regression test that test succesful mmap 32 bits till
the 2GB limit is reached.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15341
The VG_(extend_stack) call needs to be properly guarded because the
passed-in address is not necessarily part of an extensible stack
segment. And an extensible stack segment is the only thing that
function should have to deal with.
Previously, the function VG_(am_addr_is_in_extensible_client_stack)
was introduced to guard VG_(extend_stack) but it was not added in all
places it should have been.
Also, extending the client stack during signal delivery (in sigframe-common.c)
was simply calling VG_(extend_stack) hoping it would do the right thing.
But that was not always the case. The new testcase
none/tests/linux/pthread-stack.c exercises this (3.10.1 errors out on it).
Renamed ML_(sf_extend_stack) to ML_(sf_maybe_extend_stack) and add
proper guard logic for VG_(extend_stack).
Testcases none/tests/{amd64|x86}-linux/bug345887.c by Ivo Raisr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15138
