--fill-free=<hexnumber>, which cause malloc'd(etc) and free'd(etc)
blocks to be filled with the specified value. This can apparently be
useful for shaking out hard-to-track-down memory corruption. The
definedness/addressability of said areas is not affected -- only the
contents. Documentation to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7259
any wierdness on very large machines in the future. Also, double the
default size from 5MB to 10MB, on the basis that programs are now on
average twice as lardy as they were when it was set to 5MB, whenever
that was.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7256
kludges^H^H^H^H^H^H^Henhancements:
r6802: For VG_(record_ExeContext) et al, add a new parameter
(first_ip_delta) which is added to the initial IP value before the
stack is unwound. A safe value to pass is zero, which causes the
existing behaviour to be unchanged. This is a kludge needed to work
around the incomplete amd64 stack unwind info in glibc-2.5's clone()
routine.
r7059: Add a last-ditch heuristic-hack to the amd64-linux stack
unwinder, which is used when all other methods fail. Seems like GDB
has something similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7118
interface and provides full power; and "OSetWord_", which is an
easier-to-use interface for if you just want to store words.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6841
Another optimisation: allow tools to provide a final_tidy function
which they can use to mess with the final post-tree-built IR before it
is handed off to instruction selection.
In memcheck, use this to remove redundant calls to
MC_(helperc_value_check0_fail) et al. Gives a 6% reduction in code
size for Memcheck on x86 and a smaller (3% ?) speedup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6787
Allow hashtables to dynamically resize (patch from Christoph
Bartoschek). Results in the following interface changes:
* HT_construct: no need to supply an initial table size.
Instead, supply a text string used to "name" the table, so
that debugging messages ("resizing the table") can say which
one they are resizing.
* Remove VG_(HT_get_node). This exposes the chain structure to
callers (via the next_ptr parameter), which is a problem since
callers could get some info about the chain structure which then
changes when the table is resized. Fortunately is not used.
* Remove VG_(HT_first_match) and VG_(HT_apply_to_all_nodes) as
they are unused.
* Make the iteration mechanism more paranoid, so any adding or
deleting of nodes part way through an iteration causes VG_(HT_next)
to assert.
* Fix the comment on VG_(HT_to_array) so it no longer speaks
specifically about MC's leak detector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6778
different error kinds were reusing the same struct for storing their
details. Each one used some but not all the fields, and the AddrInfo was
similar, and it was very confusing.
So I changed MC_Error and AddrInfo to be tagged unions, like Vex's IRExpr and
IRStmt types. The resulting code is a little more verbose but much easier
to understand. I also split up several error kinds, which also made things
simpler. The user-visible behaviour is identical except for a couple of
very minor things that I've documented in the NEWS file for the 3.3.0
release.
Ideally I'd get rid of the Addr and Char* fields in the core Error type,
which are not always used, and do them similarly within tools. But that
would require changing the core/tool interface, so I'm leaving it for the
moment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6402
"User" errors; that is, errors resulting from client requests (check
memory range is addressible / defined).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6374
Changes resulting from porting to AIX5:
- Auxiliary primary map handling has been redone, so that the
performance penalty for hitting memory above the magic 32G limit is
much reduced, and also the number of usable maps is limited only by
how much memory is available. The current code has been tested on
64-bit AIX for processes up to about 8GB in size.
The auxiliary primary maps are now stored in an OSet, "auxmap_L2".
However, looking up in an OSet for each memory reference is
expensive. So the OSet is 'fronted' by 24-entry array which holds
pointers to the 24 most recently used auxiliary primary maps.
Accesses to this array are made faster by incrementally rearranging
it on every lookup (if the requested map is found in the array, it
is moved one element closer to the start of the array).
Logically speaking, auxmap_L1 is a cache of auxmap_L2. The L2-L1
relationship is one of inclusion; iow L2 is not a victim cache.
There is extensive new sanity check code for these structures.
- Along with the auxmap changes are semi-fast cases in mc_LOADVn_slow
and mc_STOREVn_slow. These catch naturally aligned, word-size loads
which fall into addressible memory, and handle them directly rather
than in a byte-by-byte fashion.
- Fix longstanding error with alignment checks in
{new,die}_mem_stack_N. Previously, these checked the alignment of
the new SP value without taking the stack redzone size into account.
This is only safe if the redzone size is 8-aligned. The right thing
to do is check alignment after adding on the redzone size.
- Add a new mechanism which allows specification, on the command line,
of address ranges which memcheck is to 'ignore'. Meaning that it
regards all writes to those ranges as acceptable and all reads from
those ranges as acceptable and returning initialised data. This is
done without disturbing the existing finally-balanced bitmap
machinery. Instead, in mc_record_address_error, just ignore the
error if the address falls inside an ignored-range.
There is a new command-line flag --ignore-ranges= to specify
the address ranges. Currently up to 4 non-overlapping ranges may
be specified.
This kind of thing is useful if you want to do some strange thing
like map a high-performance network card into memory and can't be
bothered to tell memcheck about it through the official channels
(intercepting syscalls/ioctls and telling aspacem about them.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6256
Here's an update to the mempool move / change client requests and sanity
checking. The following changes are present:
- Added one more (hopefully last) client request, a predicate to
test whether a mempool anchor address is currently tracked.
It turns out mozilla's arena-using code is sufficiently inconsistent
in its assumptions that it's very difficult to phrase the valgrind
client-request annotations without this request. Namely: sometime
arena-init and arena-free operations are assumed to be idempotent.
- Fixed a very rapid tool-memory leak in the mempool sanity check
routine. The previous version of the patch I posted would use all
memory even on my Very Beefy Test Machine within ~15 minutes of
browsing with firefox.
- Added a little logging code to print the counts of pools and chunks
active every ~10000 sanity checks, when running with -v.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6197
40% speedup on artificial programs which just do realloc() and nothing
else, and about a 3-4% speedup on starting kpresenter-1.5.0 and
loading a 16-slide presentation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5880
noaccess, writable, readable, other
Now they are:
noaccess, undefined, defined, partdefined
As a result, the following names:
make_writable, make_readable,
check_writable, check_readable, check_defined
have become:
make_mem_undefined, make_mem_defined,
check_mem_is_addressable, check_mem_is_defined, check_value_is_defined
(and likewise for the upper-case versions for client request macros).
The old MAKE_* and CHECK_* macros still work for backwards compatibility.
This is much better, because the old names were subtly misleading. For
example:
- "readable" really meant "readable and writable".
- "writable" really meant "writable and maybe readable, depending on how
the read value is used".
- "check_writable" really meant "check writable or readable"
The new names avoid these problems.
The recently-added macro which was called MAKE_DEFINED is now
MAKE_MEM_DEFINED_IF_ADDRESSABLE.
I also corrected the spelling of "addressable" in numerous places in
memcheck.h.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5802
Memcheck, replacing the 9-bits-per-byte shadow memory representation to a
2-bits-per-byte representation (with possibly a little more on the side) by
taking advantage of the fact that extremely few memory bytes are partially
defined.
For the SPEC2k benchmarks with "test" inputs, this speeds up Memcheck by a
(geometric mean) factor of 1.20, and reduces the size of shadow memory by a
(geometric mean) factor of 4.26.
At the same time, Addrcheck is removed. It hadn't worked for quite some
time, and with these improvements in Memcheck its raisons-d'etre have
shrivelled so much that it's not worth the effort to keep around. Hooray!
Nb: this code hasn't been tested on PPC. If things go wrong, look first in
the fast stack-handling functions (eg. mc_new_mem_stack_160,
MC_(helperc_MAKE_STACK_UNINIT)).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5791
For each byte in the range, if the byte is addressible, make it be
initialised, but if it isn't addressible, leave it alone. So it's
like a version of make_readable which doesn't alter addressibility.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5736
- when recording the non-redirected address in guest_NRADDR, also
snapshot the current R2 value, as that will be needed to run the
original safely
- As a consequence, the original-function information extracted by
VALGRIND_GET_ORIG_FN is different on ppc64-linux (2 words) from
all other platforms (1 word). So change the type of it from
void* to a new type OrigFn which can be defined differently for
each platform.
- Change the CALL_FN_* macros for ppc64-linux to save/restore
R2 values appropriately.
- ppc64-linux: detect overflow/underflow of the redirect stack
and bring Valgrind to a halt if this happens
- Update VG_CLREQ_SZB for ppc32/64 (was out of date).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5569
- fixed launcher.c to recognise ppc32/64-linux platforms properly
- lots of assembly fixes to handle func descriptors, toc references, 64bit regs.
- fixed var types in vki-ppc64-linux
Now gets as far as VG_(translate), but dies from a case of invalid orig_addr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5299
negatives, but only in the following unlikely circumstances: for an
8-byte store, which is handled by by the slow path (due to
misalignment or incomplete addressibility). In this case, the bug
caused the top 32 of the written V bits to be forced to zero
("defined"). This would not have affected the vast majority of 8-byte
stores since almost all of them would either have been handled by the
fast case or would have the top 32 V bits as zero anyway (almost
certainly both).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5222
