instruction support -- VEX side changes. See #295221.
This patch adds test cases. Also adds some minor Memcheck
instrumentation tweaks necessitated by the IR changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12476
Darwin. 10.7 is mostly built with LLVM, which uses these for
bitfield inserts, and we get a lot of false errors if the cheap
interpretation is used, alas. Could solve this much better if
we knew which of such adds came from x86/amd64 LEA instructions,
since these are the only ones really needing the expensive
interpretation, but that would require some way to tag them in
the _toIR.c front ends, which is a lot of faffing around. So
for now just use the slow and blunt-instrument solution. */
Pertains to, although does not completely solve, #242137.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12467
Note: such missing files in EXTRA_DIST are found
by check_makefile_consistency.
However, to avoid blocking the tests, the return code
of check_makefile_consistency is ignored, but the errors
it detects are pages before the end of the make regtest output.
=> it might be a good idea to move the check_makefile_consistency
as the last step of regtest: target, and not ignore its return code.
This means:
trials tests will not block make regtest
such errors will be noticed.
For the moment, just fixed the missing file in EXTRA_DIST
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12455
* Redzones for custom alloc were not protected by VALGRIND_MALLOCLIKE_BLOCK.
mc_main.c client request handling completed with protection
of the redzones.
* custom_alloc.c test modified to test this case.
* mc_errors.c modified so as to first search for a malloc-ed block
bracketting the error : for a custom allocator, a recently freed
block can have just been re-allocated.
In such a case, describing the address (e.g. in case of error)
points to the block freed rather than to the block just allocated.
If there is *also* a recently freed block bracketting the address,
the block description is changed to indicate that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12439
negatives, by marking the V bits that come from out of range parts of
the access as undefined; and hence any use of them leads to an value
error. Prior to this they were marked as defined and could be used
without error.
Behaviour of --partial-loads-ok=no (the default case) is unchanged.
Also add some testing thereof.
Fixes#294523. Modified version of a patch and testcase by Patrick
J. LoPresti (lopresti@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12430
(that holds partially defined bytes), to GC more aggressively.
Details in the comments. This largely avoids a sometimes massive
space leak, that has been observed (eg) running the Firefox test suite
on Memcheck. Without this patch it cannot complete with 4 million
nodes in the table; with the patch it completes comfortably with 50000
ish nodes. This reduces the total memory use needed for the run
from above 7GB down to 6.2GB.
Smaller improvements have been seen with other programs too. Speed
does not appear to be negatively affected.
(Based on a patch, and analysis of the problem, by Philippe Waroquiers.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12383
the memory used by sec vbit table. This logic depends
on the way sec Vbit entries are maintained.
Due to the introduction of pool alloc, this logic has
to be changed to (more) correctly compute the memory.
Verified on f12/x86 by comparing the memory reported
by the memcheck stats with what is given by --profile-heap=yes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12369
about leaked or reachable blocks)
This patch implements two new memcheck gdbserver monitor commands:
block_list <loss_record_nr>
after a leak search, shows the list of blocks of <loss_record_nr>
who_points_at <addr> [<len>]
shows places pointing inside <len> (default 1) bytes at <addr>
(with len 1, only shows "start pointers" pointing exactly to <addr>,
with len > 1, will also show "interior pointers")
Compiled and reg-tested on f12/x86, deb5/amd64, f16/ppc64.
The 'block_list' command is implemented on top of the
lr_array/lc_chunks/lc_extras arrays used during the last leak search.
NB: no impact on the memory for the typical Valgrind usage where a leak
search is only done at the end of the run.
Printing the block_list of a loss record simply consists in scanning the
lc_chunks to find back the chunks corresponding to the loss record for which
block lists is requested.
The 'who_points_at' command is implemented by doing a scan similar to
(but simpler than) the leak search scan.
lc_scan_memory has been enhanced to have a mode to search for a specific
address, rather than to search for all allocated blocks.
VG_(apply_to_GP_regs) has been enhanced to also provide the ThreadId and
register name in the callback function.
The patch touches multiple files (but most changes are easy/trivial or factorise
existing code).
Most significant changes are in memcheck/mc_leakcheck.c :
* changed the LC_Extra struct to remember the clique for indirect leaks
(size of structure not changed).
* made lr_array a static global
* changed lc_scan_memory:
to have a search mode for a specific address (for who_points_at)
(for leak search) to pass a 'current clique' in addition to the clique
leader
so as to have a proper clique hierarchy for indirectly leaked blocks.
* print_results: reset values at the beginning of the print_result of the
next leak search, rather than at the end of print_results of the previous
leak search.
This allows to continue showing the same info for loss records till a new
leak search is done.
* new function print_clique which recursively prints a group of leaked
blocks, starting from the clique leader.
* new function MC_(print_block_list) : calls print_clique for each clique
leader found for the given loss record.
* static void scan_memory_root_set : code extracted from
MC_(detect_memory_leaks) (no relevant change)
* void MC_(who_points_at) : calls scan_memory_root_set, lc_scan_memory
and VG_(apply_to_GP_regs)(search_address_in_GP_reg) to search
pointers to the given address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12357
* new files include/pub_tool_groupalloc.h and coregrind/m_groupalloc.c
implementing a group allocator (based on helgrind group alloc).
* include/Makefile.am coregrind/Makefile.am : added pub_tool_groupalloc.h
and m_groupalloc.c
* helgrind/libhb_core.c : use pub_tool_groupalloc.h/m_groupalloc.c
instead of the local implementation.
* include/pub_tool_oset.h coregrind/m_oset.c : new function
allowing to create an oset that will use a pool allocator.
new function allowing to clone an oset (so as to share the pool alloc)
* memcheck/tests/unit_oset.c drd/tests/unit_bitmap.c : modified
so that it compiles with the new m_oset.c
* memcheck/mc_main.c : use group alloc for MC_Chunk
memcheck/mc_include.h : declare the MC_Chunk group alloc
* memcheck/mc_main.c : use group alloc for the nodes of the secVBitTable OSet
* include/pub_tool_hashtable.h coregrind/m_hashtable.c : pass the free node
function in the VG_(HT_destruct).
(needed as the hashtable user can allocate a node with its own alloc,
the hash table destroy must be able to free the nodes with the user
own free).
* coregrind/m_gdbserver/m_gdbserver.c : pass free function to VG_(HT_destruct)
* memcheck/mc_replace_strmem.c memcheck/mc_machine.c
memcheck/mc_malloc_wrappers.c memcheck/mc_leakcheck.c
memcheck/mc_errors.c memcheck/mc_translate.c : new include needed
due to group alloc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12341
to let the user specify a max nr of loss records to output : on huge
applications, interactive display of a lot of records in gdb can
take a lot of time.
* mc_include.h :
- added UInt max_loss_records_output; to LeakCheckParams structure
- avoid passing LeakCheckParams by struct copy.
* modified test gdbserver_tests/mcleak to test the new parameter
* mc_main.c : parse or set max_loss_records_output in leak_check cmd
handling and calls.
* mc-manual.xml : document new leak_check parameter
* mc_leakcheck.c :
- extract printing rules logic in its own function
- in print_results, if there is a limit in LeakCheckParam,
compute from where the printing of loss records has to start
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12329
other wrappers in that it took place before the silly-args check.
Testcase and patch by Yann Droneaud (yann@droneaud.fr).
Fixes#281482
Also included is a related fix to MC_(new_block). Incrementing the
alloc counter and updating the allocated memory amount should
occur under the same condition (allocation succeeded).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12324
* move memcheck/perf/many-loss-records test to perf directory
massif/perf/many-xpts test to perf directory
* modified many-loss-records.vgperf and many-xpts.vgperf,
so as to have tool specific options prefixed with their tool
* remove directory memcheck/perf and massif/perf (containing no test anymore)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12315
At least one of the compilers for s390x nightly builds was inlining it.
Update exp files accoordingly. This should fix any residual back-trace
noise for this testcase.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12235
* initial support for Pandaboard/Linaro
* on Android/ARM, ask for non-executable stacks in the executables
* disable Memcheck's strcasestr intercept; its use of tolower()
causes the dynamic linker to fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12234
memcheck.h) by changing a bunch of VALGRIND_DO_CLIENT_REQUEST_EXPR
into VALGRIND_DO_CLIENT_REQUEST_STMT for cases where the return value
of the former would be unused. (Bart Van Assche, bart.vanassche@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12226
that if the range is partially non-addressable and it contains
undefined data, both errors are reported.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12222
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
This patch provides three improvements in the way the free list is
handled in memcheck.
First improvement: a new command line option --freelist-big-blocks
(default 1000000) specifies the size of "free list big blocks".
Such big blocks will be put on the free list, but will be re-cycled first
(i.e. in preference to block having a smaller size).
This fixes the bug https://bugs.kde.org/show_bug.cgi?id=250065.
Technically, the freed list is divided in two lists : small
and big blocks. Blocks are first released from the big block list.
Second improvement: the blocks of the freed list are re-cycled before
a new block is malloc-ed, not after a block is freed.
This gives better error messages for dangling pointer errors
when doing many frees without doing malloc between the frees.
(this does not uses more memory).
Third improvement: a block bigger than the free list volume will be
put in the free list (till a malloc is done, so as the needed memory
is not bigger than before) but will be put at the beginning of the
free list, rather than at the end. So, allocating then freeing such a
block does not cause any blocks in the free list to be released.
Results of the improvements above, with the new regression test
memcheck/test/big_blocks_freed_list: with the patch, 7 errors
are detected, 6 are giving the (correct) allocation stack.
Without the patch, only 6 errors are detected, 5 errors without
allocation stack, 1 with a (wrong) allocation stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12202
narrowing operations. The previous scheme was simply wrong and could
cause false negatives, by causing some narrowing operations to have a
defined output even when the inputs are undefined. This was what
#279698 reported. This patch is a fix for that bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12190
the tarball generated by "make dist".
With this change running regtest from the tarball produces the same
results as a regtest on a checked out repository (on x86 that is).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12172
VALGRIND_ENABLE_ERROR_REPORTING, VALGRIND_DO_ADDED_LEAK_CHECK,
VALGRIND_DO_CHANGED_LEAK_CHECK macros causes gcc 4.6 to print
a warning message about assigning a value to an unused variable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12110
must come first before the filename gets changed to bogus.S
This should unbreak the failure on x86_64. But I can't test it.
We shall see.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12099
Promote the s390x exp file to be the golden one because it has the
correct result. Add an exp-kfail file for those platforms where the testcase
fails (x86).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12098
same line for all architectures.
Promote the s390x exp file to be the golden one because it has the
correct result. Add exp-kfail files for those platforms where the testcases
fail (x86).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12097
