According to Julian initialising the previously uninitialised variable
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
Fix a regression in supp matching with obj: entries

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 a5019735-40e9-0310-863c-91ae7b9d1cf9
Fix Makefile 'MISSING EXTRA_DIST' due to addition of tc20_verifywrap.stderr.exp-glibc-2.18


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14096 a5019735-40e9-0310-863c-91ae7b9d1cf9
2 execontexts in an hash table chain are not necessarily the same size.
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 a5019735-40e9-0310-863c-91ae7b9d1cf9