be replaced if malloc() et al are replaced by a tool. This is because
different tools implement the function in different ways.
Add an appropriate malloc_usable_size() replacement to each of Memcheck,
Helgrind, DRD, Ptrcheck, Massif.
Update memcheck/tests/malloc_usable and add massif/tests/malloc_usable.
Merged from the DARWIN branch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9193
make realloc(NULL, size) behave like malloc(size), and make
realloc(ptr, 0) behave like free(ptr), as the real libc realloc does.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8666
relatively minor extensions to m_debuginfo, a major overhaul of
m_debuginfo/readdwarf3.c to get its space usage under control, and
changes throughout the system to enable heap-use profiling.
The majority of the merged changes were committed into
branches/PTRCHECK as the following revs: 8591 8595 8598 8599 8601 and
8161.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8621
I don't really understand how 'struct mallinfo' makes any sense on a
64-bit platform given that all the field sizes are 32-bit ints, and
surely at least .arena and .uordblocks and probably others could
easily exceed 32-bit range.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8149
itself, if such exist. Attempt failed (or no such uses exist :-)
Commit does not change any code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7207
sizes up to a multiple of 8 (or whatever --alignment is). This is combined
with the "admin" bytes, resulting in the "extra" bytes. Added
VG_(malloc_usable_size) to the tool interface to support this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7133
exposes a performance problem with doing m_mallocfree.c sanity checks
(at --sanity-level=3, at least), caused by slowness in
listNo_to_pszB_min. This commit fixes the problem by caching the
results of queries to listNo_to_pszB_min.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6775
make VG_(arena_free) expensive if many superblocks have to be checked
before the right one is found. This change gives the arena a
dynamically expanding sorted array of superblocks, so that finding the
superblock containing an about-to-be-freed block (findSb) is now
O(log2 n) rather than linear in the number of superblocks in the
arena. Patch from Christoph Bartoschek.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6771
performance studies by Christoph Bartoschek:
* Increase the number of freelists per arena from 18 to 112, so as
to (drastically) cut down on the amount of freelist searching that
happens.
* Increase the size of the client and tool arenas, so as to reduce
the cost of finding arenas during freeing. This is a kludge; a
better solution would be to use binary search on superblocks, as
Christoph's patches do.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6770
Track SysRes change; support bigpage allocation on AIX; make the
client-arena superblocks much bigger on AIX.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6273
interface, except for the syscall numbers, into that. Mostly this
means moving include/vki-*.h to include/vki/vki-*.h.
include/pub_tool_basics.h previously dragged in the entire kernel
interface. I've done away with that, so that modules which need to
see the kernel interface now have to include pub_{core,tool}_vki.h
explicitly. This is why there are many modified .c files -- they have
all acquired an extra #include line.
This certainly breaks all platforms except x86. Will fix shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6225
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
accessed blocks closer to the front. This speeds up malloc/free
intensive programs because evidently those searches cause a lot of
cache misses (so cachegrind tells us). For perf/heap.c on P4
Northwood, this halves the run-time (!) from 85.8 to 42.9 seconds.
For "real" code (start/exit ktuberling) there is a small but
worthwhile performance gain, of about 2 seconds out of 95.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5365
uses memory after freeing. Check the redzones for all non-client
frees, and fill all non-client freed areas with garbage. Unroll
VG_(memset) as a precautionary measure against performance lossage.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5283
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
heap blocks. The minimum size for redzones is now sizeof(void*), but
I forgot to ensure this. Massif was asking for 0 byte redzones, and this
was screwing things up on 64-bit platforms, and Massif was dying very
quickly. This should fix bugs #111090 and #111285.
The fact that Massif was this badly broken but there were only 2 bug reports
indicates that not many people are using it, at least not on AMD64.
I also added a regtest that does some basic malloc/realloc/free testing
for Massif, which would have caught this problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4492
checking of the lo/hi size fields. If we are corrupting the metadata,
this should make it more likely that we get an assertion failure rather
than an outright crash.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4480
Valgrind's allocator, by overlapping the redzones (used when blocks
are in-use) with the prev/next ptrs (used when they are free).
This reduces the overhead for a heap block allocated by the core from
32B to 16B on 32 bit machines, and from 48B to 32B on 64 bit machines.
The only conceivable downside of this is that on 64 bit machines, if
the client frees a block and then writes past the start/end of it,
it will corrupt the metadata after only 8 bytes of overwriting, rather than
16 bytes. Memcheck will have squealed to kingdom come by this time anyway.
(This won't happen on 32 bit machines because the overhead hasn't changed
for client blocks as allocated by Memcheck on 32 bit machines.)
I also tweaked the access functions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4208
