Age | Commit message (Collapse) | Author | Files | Lines |
|
memory report the actual addresses involved not just the size.
Based on patch from John Reiser <jreiser@BitWagon.com>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8440 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8369 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
Also, rename "ocache" to "ocacheL1" to be more consistent with the
comments and the rest of the otag cache code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8007 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7995 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
runs with --track-origins=yes), rather than having it statically
allocated. This is important because the cache is large (100MB) and
soaking up 100MB of address space for a non-tracking run is not good.
Unfortunately this slows down the origin tracker by 1 to 2 %.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7989 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
the primary map on 64-bit systems. Add extensive comments and
startup-time assertions.
As a result of this, fix two off-by-one errors in
MC_(helperc_MAKE_STACK_UNINIT) (unlikely to be of much significance,
but still ..). No other errors were found.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7988 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
* remove 'extern' in all the headers, as that is irrelevant and wastes
horizontal space
* fix some 64-bit uncleanness in client(-defined) block handling
* remove unneeded #includes
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7987 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
mc_errors.c, as it is relatively self contained. This reduces the
size of mc_main.c by about 1350 lines.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7986 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
support to Memcheck for tracking the origin of uninitialised values,
if you use the --track-origins=yes flag.
This currently causes some Memcheck regression tests to fail, because
they now print an extra line of advisory text in their output. This
will be fixed.
The core-tool interface is slightly changed. The version number for
the interface needs to be incremented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7982 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7745 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7540 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7398 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
--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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6902 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6855 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6488 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6449 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6401 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6396 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6378 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
"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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
- Add comments to many of the functions to make explicit their
alignment-check logic
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6314 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6083 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5992 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
(from r5791).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5973 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5954 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
addressibility error when MC_(clo_undef_value_errors) is True.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5922 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
by introducing a new "need": VG_(needs_xml_output)().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5854 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5830 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5797 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5796 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5723 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
painting/checking huge numbers of bytes resulting from client check
requests. Inlining them helps significantly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5710 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
128, 144 and 160.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5640 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
- 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 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5545 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5532 a5019735-40e9-0310-863c-91ae7b9d1cf9
|
|
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5500 a5019735-40e9-0310-863c-91ae7b9d1cf9
|