Increase the size of allocated array, so mprotect call does not end up
protecting non-allocated areas. This enables the test to work on
platforms with pagesize=64K.
Issue discovered on MIPS XLP machine with 64K pagesize.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16220
This patch forces leak_cpp_interior to be compiled using old implementation
of std::string.
Related issue #373069
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16217
This should fix issue with sendmsg test and glibc 2.22.
Glibc 2.22 introduced sysdeps/unix/sysv/linux/sendmsg.c that has
__libc_sendmsg function implementation (in comparison to earlier
implementation in syscall-template.S).
So, test suite needs to filter out this case, otherwise we get test
diffs such as:
Syscall param sendmsg(msg) points to uninitialised byte(s)
- at 0x........: sendmsg (in /...libc...)
+ at 0x........: sendmsg (sendmsg.c:28)
which are false positives.
This fixes memcheck/tests/sendmsg (stderr) on platforms with 2.22+ glibc.
Patch by Aleksandra Karadzic.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16213
As option --xtree-leak=yes is useless without a full leak report,
sets automatically full leak report if xtree leak report is requested.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16206
* New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
* New option 'xtleak' in the memcheck leak_check monitor command, to
produce the leak report in an xtree file.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16205
either to keep the free stacktrace and/or to compute full xtree memory.
Also, properly compute avg nr of IP per execontext: the avg must
be computed using the real nr of execontext stored, not the hash
table size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16199
Motivation for this change is similar to what has already been done in other
leak-* tests. That is, call CLEAR_CALLER_SAVED_REGS (currently used only on
PPC and MIPS arches) to clear temporary registers that might be holding
pointers lost in a previously called function.
This fixes memcheck/tests/leak-tree failure on some MIPS platforms.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16173
Implement CLEAR_CALLER_SAVED_REGS macro that is used for some memcheck
tests. This is done in order to clear temporary registers that still
might be holding pointers to lost memory regions.
Similar change has been made for PPC.
This fixes the following tests:
memcheck/tests/leak-cases-full (stderr)
memcheck/tests/leak-cases-summary (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/lks (stderr)
on some MIPS platforms.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16172
* memcheck will produce xtree memory profiling according to the options
--xtree-memory.
* addition of the xtmemory gdbserver monitor command.
(this is the second real xtree functional difference)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16128
Humph, this should have been part of :
16122 Add VG_(strIsMemberXA) in pub_tool_xarray.h
which means that between 16122 and this revision, these 2 unit tests
will (very probably) not compile.
That will make bissect not easy :(
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16126
The option --workaround-gcc296-bugs=yes has been depricated and
replaced with the option --ignore-range-below-sp=1024-1
Updated the vgtest file with this change.
No associated bugzilla.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16079
ignoring accesses on the stack below SP. Serves as a more modern
replacement for --workaround-gcc296-bugs, which is now deprecated.
Fixes#360571.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16073
* 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
A couple things got missed in the previous HW cap stuff needs updating patch
that cause the vbit tester to fail. The fixes are based on the patch
submitted by Mark Weilaard.
The changes were missed in Valgrind commit 16034
bugzilla 370265
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16037
Also adjust the scalar.stderr.exp to catch the new warnings.
Patch by Julian Seward <jseward@acm.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16025
pool was not auto-freed.
This was shown by:
./vg-in-place --leak-check=full ./memcheck/tests/leak-autofreepool 2 100
Without the patch, it reports 101 blocks leaked, with one block
being from the auto-free meta pool.
With the fix, there is (as expected) 100 leaked blocks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16024
e.g. using the beloz
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
This shows that freeing a mempool with significant nr of elements
has a bad effect on performance
Note that no effort has been spent to avoid leaks in this
optional perf test. This is just to analyse the time taken to
free the pool.
The above loop shows that a medium size pool (e.g. < 1000000 elts)
can already take significant time, probably due to the quadratic
algorithm to clear the pool.
Note that the increase can vary a lot, probably depending on the
way the blocks are spread in the hash table: when lucky, the quadratic
algorithm probably somewhat becomes more linear if the elements
are 'properly' ordered in the hash table by deletion order.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15986
- 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
The test suite support for the Power PC ISA 3.0 instructions added in
VEX commit 3244 is added in this commit.
bugzilla 364948
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15938
On Solaris, '%p' outputs just a hexadecimal number
without '0x' prefix. This is perfectly valid but not
understood by VG_(strtok_get_address_and_size)().
Therefore use universal PRIxPTR.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15918
Valgrind side : reproducer for the false positive memcheck
+ announce the fix (VEX side in next commit)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15905
The test suite support for the Power PC ISA 3.0 instructions added in
VEX commit 3222 is added in this commit.
Note, this is part 4 of 5. The NEWS file will be updated when the ISA 3.0
support is complete.
valgrind bugzilla 363858
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15896
