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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12360
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
This command-line option has been used to track down the recently fixed race in
drd/drd_pthread_intercepts.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12354
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12346
* 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.
perl perf/vg_perf --vg=../pool_alloc --vg=../before_pool_trunk_untouched --reps=5 perf/heap_pdb4.vgperf
-- heap_pdb4 --
heap_pdb4 pool_alloc:0.41s no: 3.0s ( 7.3x, -----) me:11.9s (29.0x, -----)
heap_pdb4 before_pool_trunk_untouched:0.41s no: 3.1s ( 7.6x, -3.7%) me:16.9s (41.1x,-41.7%)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12342
* 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
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12332
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
* 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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12326
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
* In core advanced manual, replace 3.7.0 by current release.
* cleanup in m_gdbserver/README_DEVELOPPERS
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12320
* 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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12319
not (it's not) I noticed that the code was more complex than
it needed to be. So this patch simplifies it a little.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12318
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12316
* 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
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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12314
