mc_main.c statistics has hard-coded logic to compute
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.
fix 290974 vgdb must align pages to VKI_SHMLBA (16KB) on ARM
In VG_(am_mmap_file_float_valgrind_flags),
when VKI_MAP_SHARED & flags, ensure the request length is big enough
to allow to roundup the returned advised to VKI_SHMLBA if needed.
Committed after regtest on f12/x86 and some limited validation on android arm
emulator.
Bart Van Assche [Mon, 30 Jan 2012 15:07:20 +0000 (15:07 +0000)]
Make -d (enable debug logging) work on Fedora 16 / x86.
Apparently the 32-bit Fedora 16 compiler chooses register esp to pass "&block"
to the inline assembly code in local_sys_write_stderr(). First pushing data on
the stack and next reading the contents of %0 doesn't yield the desired result
if %0 == %esp.
(fixes bug 289939 wish: complete monitor cmd 'leak_check' with details
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.
Bart Van Assche [Wed, 25 Jan 2012 20:36:27 +0000 (20:36 +0000)]
drd: Remove drd/drd_list.h again because of its GPLv2 license.
For more info about Valgrind source code licensing, see also:
[1] Top level README line 51.
[2] http://valgrind.org/docs/manual/manual-intro.html#manual-intro.overview, last paragraph.
Bart Van Assche [Thu, 19 Jan 2012 19:52:15 +0000 (19:52 +0000)]
drd: Fix a race condition in the pthread_create() intercept.
Avoid that the futex wake call in DRD_(sema_up)() can get invoked after the semaphore has
already been destroyed. This is most likely the real fix for the bug described in the
commit message of r12332.
Bart Van Assche [Wed, 18 Jan 2012 08:12:16 +0000 (08:12 +0000)]
Pool allocator: change the semantics of VG_(releasePA)() according to comment http://bugs.kde.org/show_bug.cgi?id=282230#c50.
This change also makes the semantics of releasePA match the semantics of
other release functions, e.g. those in XPCOM (see also http://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports#Release%28%29).
Add a perf test to measure the speed (and memory) of PDB handling.
* modified perf/heap.c so that it optionally creates a partially defined bytes every N bytes
* created perf/heap_pdb4.vgperf calling heap 4 (so one byte on 4 is PDB in what heap allocates).
before/after pool alloc, here are the performances on a ppc64. So, it looks like
pool alloc also significantly improves the speed of PDB handling.
Fixes 282230 group allocator for small fixed size, use it for MC_Chunk/SEc vbit
* 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.
Florian Krohm [Sun, 15 Jan 2012 21:02:44 +0000 (21:02 +0000)]
Add support for the s390's TROO insn. These are the valgrind bits.
Detect ETF2 enhancement facility using STFLE. Add testcases.
Patch by Divya Vyas (divyvyas@linux.vnet.ibm.com) with
modifications. Partial fix of #273114
Bart Van Assche [Sun, 15 Jan 2012 19:13:35 +0000 (19:13 +0000)]
drd: Set up red zone before the first instruction of a thread is run.
Avoids that DRD sporadically reports mysterious false positive conflicting accesses on
amd64 like e.g. the following:
$ ./vg-in-place --fair-sched=yes --tool=drd --read-var-info=yes --check-stack-var=yes --show-confl-seg=no drd/tests/annotate_smart_pointer 50 50
==18170== drd, a thread error detector
==18170== Copyright (C) 2006-2011, and GNU GPL'd, by Bart Van Assche.
==18170== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==18170== Command: ./annotate_smart_pointer 50 50
==18170==
==18170== Conflicting store by thread 1 at 0x7fefff8a0 size 8
==18170== at 0x400FCE: AnnotateCondVarSignal (unified_annotations.h:32)
==18170== Allocation context: unknown.
==18170==
==18170== Conflicting load by thread 1 at 0x7fefff8a0 size 8
==18170== at 0x400FDD: AnnotateCondVarSignal (unified_annotations.h:34)
==18170== by 0x401071: U_AnnotateHappensBefore (unified_annotations.h:46)
==18170== by 0x4018DD: smart_ptr<counter>::set(counter*, AtomicInt32*) (annotate_smart_pointer.cpp:239)
==18170== by 0x401778: smart_ptr<counter>::operator=(counter*) (annotate_smart_pointer.cpp:208)
==18170== by 0x401377: main (annotate_smart_pointer.cpp:326)
==18170== Allocation context: unknown.
Added a new parameter to the memcheck 'leak_check' GDB monitor command
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
* Use the arg name forClient to document the calls to VG_(am_get_advisory)
* in function VG_(am_mmap_file_float_valgrind_flags), use False/*forClient*/
instead of True (as VG_(am_mmap_file_float_valgrind_flags) is used
for "valgrind" kind of mmap only).
Regtested on f16/ppc64, deb5/amd64, Ubuntu9.10/x86
Florian Krohm [Fri, 30 Dec 2011 03:09:45 +0000 (03:09 +0000)]
Fix accounting for MC_(realloc). It was inconsistent as compared to
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).
fix 289699 vgdb connection in relay mode erroneously closed due to buffer overrun
* use PBUFSIZ+1 for buffers reading characters from gdbserver:
vgdb reads up to PBUFSIZ characters from gdbserver.
If vgdb receives a burst of packet from Valgrind gdbserver, PBUFSIZ
characters can be read. The tracing code adds a trailing \0 to
this buffer => to avoid buffer overrun, the buffers are dimensionned
with PBUFSIZ+1.
* use read_buf in function read_char, rather than directly calling read.
Florian Krohm [Mon, 26 Dec 2011 18:35:29 +0000 (18:35 +0000)]
While investigating whether bugzilla #286040 was a problem or
not (it's not) I noticed that the code was more complex than
it needed to be. So this patch simplifies it a little.
Florian Krohm [Sat, 24 Dec 2011 21:50:53 +0000 (21:50 +0000)]
Beef up VG_(strerror) to provide correct messages for the
errno codes in asm-generic/errno-base.h (on linux).
The error strings were obtained by calling strerror natively in
Linux.
Extend vki-linux.h accordingly. vki-darwin.h already had
those errno codes.
Add testcase. This fixes #287858.
Fix 247386 make perf does not run all performance tests :
* 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)
* none/tests/linux/mremap3.vgtest : new test
mremap3.c based on testcase provided by Jan Engelhardt
* coregrind/m_syswrap/syswrap-generic.c
- The two 'no-thrash checks' that were introduced to fix bug #129866
were (probably) broken when adress space manager was reworked.
The new VG_(am_get_advisory_client_simple) returns NULL for a free
segment, but the check was based on checking not NULL and then
that the state is free.
=> replaces these two local checks by a call to the new
am Bool VG_(am_covered_by_single_free_segment) function.
* coregrind/pub_core_aspacemgr.h
coregrind/m_aspacemgr/aspacemgr-linux.c
- new function Bool VG_(am_covered_by_single_free_segment)
Bart Van Assche [Sat, 17 Dec 2011 12:53:23 +0000 (12:53 +0000)]
Add a configure test for detecting whether gcc supports atomic operations on
64-bit integers on 32-bit platforms. Apparently newer gcc versions support
this but older versions not. Thanks to Philippe Waroquiers for reporting this.
rev 12001 has introduced a regression in VG_(env_remove_valgrind_env_stuff):
to avoid modifying a possibly read-only env string, the string is duplicated,
and the copy is modified. However, mash_env_column modifies the string
"in-place". The modified string was not put back in the env (and could not,
because the src string is only partially copied).
This means that the valgrind preload strings were not cleaned up and
when a 32 bit executable execs a 64 bits (or vice versa: 64 bit execs 32 bits),
LD_PRELOAD contains both the 32 bits and 64 bits versions of Valgrind
vgpreload.... => ld.so then gives an error msg, as it can't preload either
the 32 or the 64 bits version.
The patch fixes this by duplicating the whole env string, and passing
to mash_colon_env a pointer to the correct offset in the whole env string.
The duplicated string is replacing the original entry in envp.
This patch adds two regression tests : none/tests/allexec32 and
none/tests/allexec64. On a bi-arch valgrind, these will be 32bits and 64 bits
executables, exec-ing each other. On a single arch, one will be a symlink
to the other (to avoid different .exp files, and still test exec).
Give a better help message for gdbserver when VALGRIND_LIB
is set. This ensures a correct help msg is given when
the valgrind installation is moved, and VALGRIND_LIB is
then set to the new valgrind lib location.
Note it does not improve the help msg when valgrind
is run "in place" (e.g. when using vg-in-place).
(Patch from Paul Pluzhnikov).
projects / thirdparty / valgrind.git / log
