as this makes the inner stacktraces easier to understand
and also it exercises the inline unwinding somewhat already,
waiting for a (possible) activation by default of --read-inline-info
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14101
So, ensure that when size differs, we do not start to compare them,
as this could otherwise cause a read buffer overrun
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14097
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
* Add a POST_MEM_WRITE for kernelrpc_mach_vm_map_trap
* fix a compiler complaint caused by lack of a cast
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14085
specified with --with-tmpdir at configuration time or with TMPDIR
at runtime. Doing so fixes the symptom reported in BZ #332765.
Also fix an incorrect error message.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14077
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
the inlined info of a big executable.
On a slow pentium, reading the inline info now takes 5.5 seconds.
The optimisation consists in having per dw3 abbreviation a structure
allowing to skip efficiently the non interesting DIEs (i.e. the DIEs
the parse_inl_DIE is not interested in).
Mostly, the idea is to avoid calling the image abstraction, and replace
this by just advancing the cursor (i.e. addition rather than a bunch
of function calls to read the data).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14075
