gcc 4.4 and 4.5 has a bug which causes miscompilation of mc_main.c:
args are not correctly given to VG_(am_munmap_valgrind).
This causes the secondary map entries to not be unmapped
(which can cause unlimited memory growth)
and/or causes the assert on VG_(am_munmap_valgrind) result to fail.
Removing the pragma optimize from mc_main.c and inserting it instead
in Makefile.all.am for x86 solves the gcc bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12564
It is suspected that there is a bug in the call to VG_(am_munmap_valgrind).
At first sight, it looks like a bug in gcc version 4.4.5 (Debian 4.4.5-8)
which seems to pass wrong arguments from mc_main.c to aspace mgr function.
Some tests are failing on gcc20 with this assert a.o.
./vg-in-place ./perf/bz2 x
gives an assert.
The bug does not happen if Valgrind is compiled with gcc 4.7.0.
On gcc20, the new tests failing with this assert are:
memcheck/tests/linux/lsframe1 (stderr)
memcheck/tests/linux/lsframe2 (stderr)
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/origin5-bz2 (stdout)
memcheck/tests/vcpu_bz2 (stdout)
memcheck/tests/vcpu_bz2 (stderr)
The assert is committed so as to see other platforms
where this is failing.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12563
* pub_tool_redir.h : define the prefix to be used for "soname synonym"
place holder
* vg_replace_malloc.c : define synonym place holder for malloc related
functions
* m_redir.c : when detecting a soname synonym place holder redir spec, search
in clo_soname_synonyms if there is a synonym pattern.
If yes, replace the soname pattern. If not, ignore the redir spec.
* various files: implement or document the new clo --soname-synonyms
* new test memcheck/tests/static_malloc.vgtest
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12559
test group and test exponent instructions dtstdc, dtstdcq, dtstdg,
dtstdgq, dtstex and dtstexq. Bug #298862. (Carl Love,
carll@us.ibm.com and Maynard Johnson, maynardj@us.ibm.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12546
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
