--read-var-info=yes is very memory and cpu intensive.
This patch ensures that even witout --read-var-info=yes that
the frame where the address point is reported in the address
description.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13991
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c
At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).
The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).
Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp
The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965
with i-cache invalidation to be more consistent with new d-cache
flushing functionality, so as to track changes in Vex r2852:
Ijk_TInval -> Ijk_InvalICache
TISTART -> CMSTART (CM == "Cache Management")
TILEN -> CMLEN
VEX_TRC_JMP_TINVAL -> VEX_TRC_JMP_INVALICACHE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13934
medium resolution (4 callers) used to compare errors.
To look at the strange side effect, do:
./vg-in-place -v --suppressions=memcheck/tests/suppfreecollision.supp memcheck/tests/suppfree activatenondangerouserror
You obtain at the end:
...
--19240-- used_suppression: 2 suppressnondangerouserror memcheck/tests/suppfreecollision.supp:2
...
showing that the suppression aiming at suppressing a nondangerous error has in fact
suppressed more than expected.
This is because m_errormgr.c compares the exe_context in medium resolution/4 calls
(or low resolution/2 calls once 100 errors have been collected).
The error machinery first encounters the non dangerous error. This error is suppressed,
because all callers match the suppression entry. In particular, we have
in the stacktrace the function ok_to_suppress_double_free_from_this_fun
Then the error machinery encounters the second error.
The stacktrace of the 2nd error has the same first 4 callers than the non
dangerous error. So the 2nd error is considered equal to the first one
and is (unexpectedly in my opinion) suppressed.
This looks a bug (or at least something very surprising).
(the doc mentions the fact that errors are 'commoned up' on 4 callers, but
I am not sure the above side effect was understood).
There are several ways this can be improved, some are more easier than other
* have --error-resolution=low/med/high
similar to the memcheck --leak-resolution=low/med/high
(which default value would we take for this new clo ?)
* have a lot more intelligent error comparison:
when comparing an error with a suppressed error, one must
check that the callers used for suppression are equal.
This looks difficult to implement and probably a significant slow down
in the error machinery, which will impact applications producing
many suppressed errors (e.g. helgrind + some pthread lib errors).
This also implies more memory (e.g. one byte per caller in the
error, to indicate which caller(s) were used to suppress.
Still wondering what to do with * and ... ?
* have a somewhat more intelligent error comparison:
Instead of comparing only the callers used for suppression, we
compare the range first..last caller used (so including some
callers in the range that were not used to suppressed if e.g.
a ... matching was put in the supp entry).
Probably still a slowdown (less than previous solution ?)
and less memory than the previous solution.
But also not completely clear how to compute the range.
* always re-evaluate the suppression : this will very probably be
a significant slow down.
* do nothing, as nobody complained about this behaviour up to now :)
* ??? any other idea
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13914
See comments in MC_(helperc_STOREV8) for a detailed explanation.
On modern cpu, this gives a few percent speed improvement for
some perf tests, and reduces the nr of undistinguished secondary
map.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13904
* add a function Bool VG_(parse_enum_set) in pub_tool_libcbase.h/m_libcbase.c
(close to Bool VG_(parse_Addr)
* Implement Bool MC_(parse_leak_heuristics) and MC_(parse_leak_kinds)
as a call to VG_(parse_enum_set)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13898
VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE and
VALGRIND_ENABLE_ADDR_ERROR_REPORTING_IN_RANGE
and supporting machinery for managing whole-address-space sparse
mappings. n-i-bz. In support of
https://bugzilla.mozilla.org/show_bug.cgi?id=970643
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13884
generate two consecutive 32bit loads instead of one 64bit load. Because of that
in error log we have two conflict loads of size 4 instead of one conflict load
of size 8.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13883
end of the string, so we need to add an extra element in string 's' for the null
terminator.
VG_(strcpy) ( HChar* dest, const HChar* src ) function copies the string pointed
to by src, including the null terminator ('\0'), to the buffer pointed to by dest.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13880
Apparently needed for generating some kinds of error messages, even
when not doing origin tracking, strangely enough.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13841
We check evp.sigev_notify_thread_id only if evp->sigev_notify has
SIGEV_THREAD_ID set. But before checking we need to make sure accessing
evp->sigev_notify is valid.
Fix memcheck/tests/x86-linux/scalar.stderr.exp output.
We now produce separate warnings for the 3 different fields.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13837
After the thread is detached not all thread memory is freed. This memory (dtv-dynamic thread vector)
can be used by the main thread. There are two types of run-time handling of TLS.
Difference is in the position of memory. It can be either before the thread pointer or
after the thread pointer.
Taken form the document http://www.akkadia.org/drepper/tls.pdf:
"Variant I for the thread-local storage data structures were developed
as part of the IA-64 ABI. Being brand-new, compatibility was no issue. The thread
register for thread t is denoted by tpt. It points to a Thread Control Block (TCB) which
contains at offset zero a pointer to the dynamic thread vector dtvt for the thread.
Variant II has a similar structure. The only difference is that the thread pointer
points to a Thread Control Block of unspecified size and content. Somewhere the TCB
contains a pointer to the dynamic thread vector but it is not specified where. This is
under control of the run-time environment and the pointer must not be assumed to be
directly accessible; compilers are not allowed to emit code which directly access the
dtvt."
Because of this we have two types of error when the program ends:
possibly lost, and definitely lost.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13761
* addition of VG_(needs_print_stats) in pub_tool_tooliface.h
* use the above in memcheck and helgrind
* output valgrind stats and calls print_stats in server.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13760
Iop_GetMSBs8x16, since the presence of those usually implies PMOVMSKB
instructions in the block, which can mean "inlined string operations".
Reduces the noise level a lot in some icc12 -O2 generated sequences.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13757
r13682 Initial cut at 3.9.0 release notes.
r13683 Remove duplicate NEWS entries for 3.9.0.
r13689 Minor docs/NEWS fixes
r13690 Documentation updates for 3.9.0.
r13691 More documentation updates, re leak-checker changes
r13692 NEWS: Note increased max mem size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13724
Move memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and
add several intercepts for SSE-variants. Include that source file from
drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and
memcheck/mc_replace_strmem.c.
Merge memcheck/tests/filter_memcpy into tests/filter_stderr_basic.
Update tests/check_headers_and_includes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13719
This change reduces the time needed to run the memcheck regression tests
with 2% on my development system.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13716
only reachable via other thread live register
The exiting thread will have its registers considered as not reachable
anymore, registers of other threads will be considered reachable.
This is ensured by using a different exit reason for the
exiting thread and for the other threads.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13670
vaddcuq, vadduqm, vaddecuq, vaddeuqm,
vsubcuq, vsubuqm, vsubecuq, vsubeuqm,
vbpermq and vgbbd.
The completes adding the Power ISA 2.07 support.
Bugzilla 325816
VEX commit id 2790
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13653
Option -v outputs a list of used suppressions. This only gives
the nr of times a suppression was used.
For a leak search, this only gives the nr of loss records that
have been suppressed, but it does not give additional needed details
to understand more precisely what has been suppressed
(i.e. nr of blocks and nr of bytes).
=> Add in the tool interface update_extra_suppression_use and
print_extra_suppression_info functions to allow the tool to record
additioonal use statistics for a suppression. These statistics
can be done depending on the error (and its data) which is suppressed.
Use this in memcheck for the leak suppressions, to maintain and output
the nr of blocks and bytes suppressed by a suppression during
the last leak search.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13651
On s390, the linux kernel does not deliver the exact address that
caused a SEGV but rather this address rounded down to a page boundary.
Also, old kernels do not deliver the address that caused a SIGBUS,
but deliver 0.
So, on s390, handle SIGSEGV and SIGBUG by always skipping one page
starting from the current value of the ptr scanning position.
As we need a correct value of ptr on this platform in the longjmp-ed
code, ptr is marked as volatile.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13648
This commit adds the testcases for the following instructions:
vpmsumb, vpmsumh, vpmsumw, vpmsumd, vpermxor, vcipher, vcipherlast,
vncipher, vncipherlast, vsbox,
vclzb, vclzw, vclzh, vclzd,
vpopcntb, vpopcnth, vpopcntw, vpopcntd,
vnand, vorc, veqv,
vshasigmaw, vshasigmad,
bcdadd, bcdsub
The VEX commit that added the support for the above instructions was
commit 2789.
The patch is for Bugzilla 325628
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13646
* initialise leak_check heuristic parameter in the leak_check monitor command
* show the default value (none heuristic) in the monitor help command
(none value chosen as default as this gives a backward compatible
behaviour).
* document the heuristic leak check parameter in memcheck manual
monitor command section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13631
