The leak search must recover if unreadable pages are scanned.
This test creates such unreadable pages by doing non SIMD mprotect
syscall (not seen by the aspacemgr).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12972
an immediate constant as the shift amount. This is needed for
powerpc Iop_ShlD64 etc. What it basically means that we do not
iterate over the bits in the 2nd operand because there are no
V-bits to set. An immediate constant is always completely defined.
Fixes bugzilla #305948.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12969
Testcase, vbit tester update, memcheck support for the new IROps,
NEWS announcement and opcode list update.
Patch by Christian Borntraeger (borntraeger@de.ibm.com).
Vbit tester tweaks by myself.
Fixes bugzilla #274695.
See also companion patch VEX r2496.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12921
they cause assertion failures.
Do not test Iop_CmpORDxyz on ppc because the vbit tester does not
support them. This is just so we don't have to add another .exp file for ppc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12910
The tester is located in memcheck/tests/vbit-test.
It needs the following support on the valgrind / VEX side:
(1) a new client request VG_USERREQ__VEX_INIT_FOR_IRI
(2) a new "special instruction" on all architectures inserted via
VALGRIND_VEX_INJECT_IR
(3) VEX changes to detect the special insn and insert IR (ir_inject.c)
The README file in vbit-test has some more information.
See also VEX r2490. Fixes bugzilla #300102.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12906
Iop_Mul8, Iop_Sar8, Iop_CmpwNEZ32, and Iop_8HLto16.
With this change mc_translate now handles all IR ops which are architecture
independent, except Iop_LeftXYZ and Iop_Max32U.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12884
Before this patch, matching an error stack trace with many suppression
patterns was implying to repeating the translation of the IPs of the
stack trace to the function name or object name for each suppr pattern.
This patch introduces a "lazy input completer" in the generic match
so that an IP is (in the worst case) translated once to its function
name and once to its object name.
It is a "lazy" completer in the sense that only the needed IP to fun or obj
name are done.
On a artificial test case, has given a factor 3 in performance.
On another big (real) application, gave a factor 2 to 3.
(there was less matching to do, but probably more debug info to search).
match-overrun.supp completed to have non matching suppr first to
better exercise the lazy completer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12824
* For tools replacing the malloc library (e.g. Memcheck, Helgrind, ...),
the option --redzone-size=<number> allows to control the padding
blocks (redzones) added before and after each client allocated block.
Smaller redzones decrease the memory needed by Valgrind. Bigger
redzones increase the chance to detect blocks overrun or underrun.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12807
MIPS has different signal values, so it has to have its own expected output for
the tests that deal with signal values.
This fixes (false) failure in memcheck/tests/sigkill.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12794
WRT the memcheck test: the good news is we get all the complaints
we want. The bad news is:
- the line numbers from within do_cu21 are off
- there are 2 complaints when attempting to convert from
an uninitialised input buffer instead of one. One of them has a
completely bogus line number.
Possibly due to bad debug info? Let's see what happens on machines
with more recent GCCs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12765
This means, that any guest state and/or memory accesses of the helper (and
complaints about those) only occur if the guard expression is true at runtime.
Definedness of parameters that the helper might have is *always* checked,
as parameters are evaluated regardless of the guard expression.
New functions: expr2vbits_guarded_Load and gen_guarded_load_b.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12762
Scanning 1GB of random values made of 200_000 malloc-ed block is
(on amd64) changing from (about) 17 seconds to (about) 10 seconds.
On x86, it goes from 153 seconds to 129 seconds.
(this huge difference between x86 and amd64 leak search time
for this random test is because a random value has about one chance
on 4 to be in the addressable memory on x86 and so the dichotomic
search in the list of malloc-ed blocks is called for a lot more
values than on amd64).
Basically, there are 3 optimisations:
1. call MC_(is_within_valid_secondary) only at the beginning of a
secondary map (and not for each Word).
2. call SETJMP only at the beginning of a page (and not for each Word)
3. Validate an aligned word using get_vabits8 rather than get_vabits2.
Each of the above optimisation more or less improves by 2 seconds.
(to go from 17 seconds to 10 seconds).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12756
The leak search verifies if an address scanned is in a fully
unaddressable secondary map (64 Kb).
However, the function checking that wrongly verifies
if the address is in an ignore range.
So, if the scan encounters one or more bytes in an ignore
range, the leak scan will erroneously skip the rest of
the 64Kb chunk.
The solution is to not test for ignore range in the function
MC_(is_within_valid_secondary) :
The fact that the address is in an ignore range is in any case
verified in the call to MC_(is_valid_aligned_word), which
is called for every Word just after.
This bug can cause false positive leaks in case small
ignore ranges are specified.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12734
User is supposed to mark the superblock(s) of a mempool as noaccess.
As Valgrind objective is to find bugs for users which are doing bugs, let's even
find (some) bugs if the user has a bug in the bug detection code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12714
This limit is large enough for all practical purposes. It exists
only to sanity check the value specified with --num-callers.
Be frugal in record_ExeContext_wrk and only allocate on the stack
as many frames as needed.
Testcase included.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12685
