The bug itself was solved in 3.12 by the addition of __gnu_cxx::__freeres
in the libstdc++ and have valgrind calling it before exit.
However, depending on the version of the libstdc++, the test leak_cpp_interior
was giving different results.
This commit adds some filtering specific to the test, so as to not depend
anymore of the absolute number of bytes leaked, and adds a suppression entry to
ignore the memory allocated by libstdc++.
This allows to have only 2 .exp files, instead of 4 (or worse, if
we would have to handle yet other .exp files depending on the libstdc++
version).
* rename macro VALGRIND_CREATE_META_MEMPOOL
to VALGRIND_CREATE_MEMPOOL_EXT
* abort execution if a pool is marked as auto_free but is not a meta pool
+ removed test leak-autofreepool-3.vgtest, which now aborts.
* reword/clarify valgrind.h explanations for meta pool
* similarly reword/clarify the manual
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16042
Based on a patch from Ruurd Beerstra
but reworked VG_(HT_remove_at_Iter) so that
the function is implemented without touching the rest of m_hashtable.c
to ensure no performance impact on other hash table usages.
Testing with
for f in 1 2 3 4 5 6 7 8 9; do echo $f; time ./vg-in-place -q ./memcheck/tests/leak-autofreepool 2 $(expr $f \* 100000); done|&grep user
With the patch :
user 0m0.524s
user 0m0.660s
user 0m0.784s
user 0m0.916s
user 0m1.064s
user 0m1.192s
user 0m1.316s
user 0m1.496s
user 0m1.632s
Without the patch, the same gives:
user 0m4.464s
user 0m16.776s
user 0m24.472s
user 1m5.544s
user 1m21.168s
user 1m40.500s
user 1m54.884s
user 4m58.308s
user 5m34.060s
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16041
- Auto-frees all chunks assuming that destroying a pool destroys all
objects in the pool
- Uses itself to allocate other memory blocks
Unit tests included.
Fixes BZ#367995
Patch by: Ruurd Beerstra <ruurd.beerstra@infor.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15984
- zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
- zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
Fixes BZ#303877
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15868
The new memcheck/tests/arm64-linux/scalar test is based on the
memcheck/tests/x86-linux/scalar test and contains all syscalls
that are also available on arm64. To make comparison of exp results
easier the order of the tested syscalls is the same as on x86.
This enables a couple extra arm64 syscalls. Part of the fix for
bug #359503 - Add missing syscalls for aarch64 (arm64).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15825
C++ allocator from Solaris Studio allocates for std::string
57 bytes instead of former 40 bytes on 64-bit, and 45 bytes instead of 28 on 32-bit.
Confirmed with truss and --trace-alloc=yes.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15775
On Solaris, the stack frame looks like:
<stack>
<frame>
<ip>0x........</ip>
<obj>/lib/amd64/libc.so.1</obj>
<fn>kill</fn>
</frame>
<frame>
<ip>0x........</ip>
<obj>.../gdbserver_tests/gone</obj>
<fn>(below main)</fn>
</frame>
</stack>
because Solaris libc does not currently contain DWARF CFI and
stack unwinder gets only return address from _start().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15750
This implements the interception of all globally public allocation
functions by default. It works by adding a flag to the spec to say the
interception only applies to global functions. Which is set for the
somalloc spec. The librarypath to match is set to "*" unless the user
overrides it. Then each DiSym keeps track of whether the symbol is local
or global. For a spec which has isGlobal set only isGlobal symbols will
match.
Note that because of padding to keep the addresses in DiSym aligned the
addition of the extra bool isGlobal doesn't actually grow the struct.
The comments explain how the struct could be made more compact on 32bit
systems, but this isn't as easy on 64bit systems. So I didn't try to do
that in this patch.
For ELF symbols keeping track of which are global is trivial. For pdb I
had to guess and made only the "Public" symbols global. I don't know
how/if macho keeps track of global symbols or not. For now I just mark
all of them local (which just means things work as previously on platforms
that use machos, no non-system symbols are matches by default for somalloc
unless the user explicitly tells which library name to match).
Included are two testcases for shared libraries (wrapmalloc) and staticly
linked (wrapmallocstatic) malloc/free overrides that depend on the new
default. One existing testcase (new_override) was adjusted to explicitly
not use the new somalloc default because it depends on a user defined
new implementation that has side-effects and should explicitly not be
intercepted.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15726
inline functions. There is no command line flag so suppress that particular
warnings. So let's suppress all warnings for this testcase.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15473
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
Revision 14976 causes a regression : stacktrace produced when the
stack has not yet been extended to cover SP will only contain one
element, as the stack limits are considered to be the limits of
the resvn segment.
This patch fixes that, by taking Resvn/SmUpper segment into
account to properly compute the limits.
It also contains a new regtest that fails with the trunk
(only one function in the stacktrace)
and succeeds with this patch (the 2 expected functions).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15046
memcheck/tests/Makefile.am:1: error: wrap8.stderr.exp-ppc64 is missing in EXTRA_DIST
memcheck/tests/Makefile.am:1: error: wrap8.stdout.exp-ppc64 is missing in EXTRA_DIST
memcheck/tests/Makefile.am:1: error: wrap8.stdout.exp2 is in EXTRA_DIST but doesn't exist
memcheck/tests/Makefile.am:1: error: wrap8.stderr.exp2 is in EXTRA_DIST but doesn't exist
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15015
Since valgrind 3.9.0 the STABS support was already disabled completely.
But the code was still there being compiled and we were still searching
for stabs sections in binaries. Completely remove all sources, tests and
references. Add a note to coregrind/m_debuginfo/README.txt to mention
the old code can be found in the subversion repository.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14550
none/tests/ppc32/jm-insns.c and none/tests/ppc64/jm-insns.c.
The BE and LE output expect files are updated as well.
There is no Bugzilla related to this update. The issue
was found and the initial patch and BE output update
was done by Florian Krohm <florian@eich-krohm.de>.
Carl Love <cel@us.ibm.com> added the LE output update.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14466
An address below the sp will be described as being on a stack, but below sp.
The stack for such an address is found in the registered stacks.
Also, if there is a guard page at the end of the stack (lowest address)
an address in this page will be described as being in thread guard page.
A guard page is recognised as being a page not readable/writable/executable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14399
Suppression matching logic was changed to understand inlined function calls.
A regression was introduced while doing this. This regression could
cause false positive supp matches or false negative supp matches, when
obj: lines are used.
This patch fixes the regression, and adds 2 tests (one that was failing
with false positive, one that was failing with false negative).
The fix is relatively small (3 places where there was an "off or excess by one").
However, a lot more tracing was added in the supp matching logic, as this
logic is quite complex (for performance reasons mostly).
We might need more tests to properly cover supp matching logic.
So, giving -d -d -d -d produces a trace showing how a stacktrace was expanded
by the input completer and which suppression (if any) it matched.
Below is an example of trace. It shows a begin/end marker. The end marker
indicates if a supp matched. Then it shows the stack trace, and the state
of the lazy "input completer" used for the matching.
In the below, the trace shows that there are 3 IPs in the stacktrace
(n_ips 3) : Two are not shown (below main), and one IP corresponds
to main calling 4 inlined functions (so we have only one IP for 5 entries
in the stacktrace).
The state of the input completer shows that 2 IPs were expanded, resulting
in 6 expanded fun: or obj: lines.
The offset shows that ips0 corresponds to the entries [0,4] in ip2fo->funoffset
or ip2fo->objoffset.
This tracing should make it more clear what was used to match a stacktrace
with the suppression entries.
--10314-- errormgr matching begin
--10314-- errormgr matching end suppression main_a_b_c_d ./memcheck/tests/inlinfosupp.supp:2 matched:
==10314== at 0x8048667: fun_d (inlinfo.c:7)
==10314== by 0x8048667: fun_c (inlinfo.c:15)
==10314== by 0x8048667: fun_b (inlinfo.c:21)
==10314== by 0x8048667: fun_a (inlinfo.c:27)
==10314== by 0x8048667: main (inlinfo.c:66)
n_ips 3 n_ips_expanded 2 resulting in n_expanded 6
ips 0 0x088048667 offset [0,4] fun:fun_d obj:/home/philippe/valgrind/objcompl/memcheck/tests/inlinfo
fun:fun_c obj:/home/philippe/valgrind/objcompl/memcheck/tests/inlinfo
fun:fun_b obj:/home/philippe/valgrind/objcompl/memcheck/tests/inlinfo
fun:fun_a obj:/home/philippe/valgrind/objcompl/memcheck/tests/inlinfo
fun:main obj:/home/philippe/valgrind/objcompl/memcheck/tests/inlinfo
ips 1 0x0822abb5 offset [5,5] fun:(below main) obj:<not expanded>
Complete tracing (including individual pattern matching) can be activated
by recompiling m_errormgr.c after changing
#define DEBUG_ERRORMGR 0
to
#define DEBUG_ERRORMGR 1
This detailed tracing will be shown between the begin/end marker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14095
won't affect the test adversely -- so let's do this and get rid of
the special compilation again. Also guard against future compiler smartness
tricking the compiler into believing the variable is actually used.
So the loop won't get optimised away.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14094
The name is not necessarily found in the abstract origin, it can be
in a referred to specification.
If both a name and a DW_AT_specification is found in the abstract origin,
the name will have priority over the name of the specification.
(unclear if that can happen)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14076
showing inlined function calls.
See 278972 valgrind stacktraces and suppression do not handle inlined function call debuginfo
Reading the inlined dwarf call info is activated using the new clo
--read-inline-info=yes
Default is currently no but an objective is to optimise the performance
and memory in order to possibly set it on by default.
(see below discussion about performances).
Basically, the patch provides the following pieces:
1. Implement a new dwarf3 reader that reads the inlined call info
2. Some performance improvements done for this new parser, and
on some common code between the new parser and the var info parser.
3. Use the parsed inlined info to produce stacktrace showing inlined calls
4. Use the parsed inlined info in the suppression matching and suppression generation
5. and of course, some reg tests
1. new dwarf3 reader:
---------------------
Two options were possible: add the reading of the inlined info
in the current var info dwarf reader, or add a 2nd reader.
The 2nd approach was preferred, for the following reasons:
The var info reader is slow, memory hungry and quite complex.
Having a separate parsing phase for the inlined information
is simpler/faster when just reading the inlined info.
Possibly, a single parser would be faster when using both
--read-var-info=yes and --read-inline-info=yes.
However, var-info being extremely memory/cpu hungry, it is unlikely
to be used often, and having a separate parsing for inlined info
does in any case make not much difference.
(--read-var-info=yes is also now less interesting thanks to commit
r13991, which provides a fast and low memory "reasonable" location
for an address).
The inlined info parser reads the dwarf info to make calls
to priv_storage.h ML_(addInlInfo).
2. performance optimisations
----------------------------
* the abbrev cache has been improved in revision r14035.
* The new parser skips the non interesting DIEs
(the var-info parser has no logic to skip uninteresting DIEs).
* Some other minor perf optimisation here and there.
In total now, on a big executable, 15 seconds CPU are needed to
create the inlined info (on my slow x86 pentium).
With regards to memory, the dinfo arena:
with inlined info: 172281856/121085952 max/curr mmap'd
without : 157892608/106721280 max/curr mmap'd,
So, basically, inlined information costs about 15Mb of memory for
my big executable (compared to first version of the patch, this is
already using less memory, thanks to the strpool deduppoolalloc.
The needed memory can probably be decreased somewhat more.
3. produce better stack traces
------------------------------
VG_(describe_IP) has a new argument InlIPCursor *iipc which allows
to describe inlined function calls by doing repetitive calls
to describe_IP. See pub_tool_debuginfo.h for a description.
4. suppression generation and matching
--------------------------------------
* suppression generation now also uses an InlIPCursor *iipc
to generate a line for each inlined fn call.
* suppression matching: to allow suppression matching to
match one IP to several function calls in a suppression entry,
the 'inputCompleter' object (that allows to lazily generate
function or object names for a stacktrace when matching
an error with a suppression) has been generalised a little bit
more to also lazily generate the input sequence.
VG_(generic_match) has been updated so as to be more generic
with respect to the input completer : when providing an
input completer, VG_(generic_match) does not need anymore
to produce/compute any input itself : this is all delegated
to the input completer.
5. various regtests
-------------------
to test stack traces with inlined calls, and suppressions
of (some of) these errors using inlined fn calls matching.
Work still to do:
-----------------
* improve parsing performance
* improve the memory overhead.
* handling the directory name for files of the inlined function calls is not yet done.
(probably implies to refactor some code)
* see if m_errormgr.c *offsets arrays cannot be managed via xarray
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14036
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
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
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
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
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
