#define N_FRAMES 8
(defined in libhb_core.c:3888)
implies that 'other thread' stack traces are limited to 8,
even with a bigger --num-callers.
=> document this in the manual to avoid that a user believes this is a
bug in the stack trace logic of Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12767
-new_linker to the stuff given to the linker, else link failures
result on x86. Based on a suggestion by Christoph Erhardt. Fixes
#295427.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12766
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
Valgrind was crashing systematically on Android 4.1.
This crash is caused by AT_IGNORE-ing AT_BASE.
This AT_IGNORE was needed to have breakpoints in shared libs
be handled properly (not very clear what is the problem
in the interaction between Valgrind GDBSERVER, AT_BASE and GDB).
Waiting to better understand all this, as a temporary bypass,
this patch ensures we do not ignore the AT_BASE on android.
The possible consequence is that breakpoints might be inserted
by the Valgrind gdbserver at wrong addresses in shared lib.
(any feedback on that is welcome).
Valgrind was build and then "proved" to work on Android emulator 4.0
and emulator 4.1, by using memcheck on one executable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12758
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
(spotted by Julian)
Note: there is a second occurence of call to track_post_mem_write in the
same file; but this second occurence is better done with an "if".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12755
The header file has been extended with the missing syscall numbers for MIPS,
and sys_prlimit64 has been enabled. This will make none/tests/rlimit64_nofile
pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12752
Support has been added to the tests for MIPS32 revision 1. Previously, all the
tests had to be compiled for MIPS32r2 platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12751
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
* when cond var is destroyed, in the PRE, report an error if nwaiters > 0.
* when cond_wait succeeds, get the cond var but do not create one in helgrind
(it must exist if cond_wait was done).
Report an error if cond not found (assuming this is caused by a destroy
done while the thread was cond_wait-ing).
* added a test
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12721
The frsqrte and vrefp instructions produce an approximate result.
According to the ISA document for the POWER processor, the result will
vary in its precision for different processor implementations. This patch
fixes the masks to be applied to the results to remove the variability
in the results. The expected output files are also updated to reflect the
change in the result given the new masking of the result.
patch from Carl Love <cel@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12720
