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
remaining ones have no interesting effect, but I left them in.
Also simplify the signature for VG_(get_memory_from_mmap_for_client)().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4045
I've changed it so it now is, which makes it consistent with the
other 'needs'. Because of this, I was also able to invert the dependence
between m_mallocfree and m_tooliface, which is related to setting
the redzone size for client heap blocks. As a result, m_tooliface
now doesn't depend on anything except pub_core_basics.h, hooray!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3979
m_libcmman, next to VG_(get_memory_from_mmap). Removes the (direct)
dependence of m_mallocfree on m_aspacemgr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3962
- Broke part of m_scheduler off into a new module m_threadstate. It
contains ThreadState, VG_(threads)[] and some basic operations on the
thread table. All simple stuff, the complex stuff stays in m_scheduler.
This avoids lots of circular dependencies between m_scheduler and other
modules.
- Managed to finally remove core.h and tool.h, double hurrah!
- Introduced pub_tool_basics.h and pub_core_basics.h, one of which is
include by every single C file.
- Lots of little cleanups and changes related to the above.
- I even did a small amount of documentation updating.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3944
needs to #include pub_core_mallocfree.h. As a result, we need
to #include it explicitly everywhere else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3881
As part of this, killed the VG_STRINGIFY macro, which was used to expand
out names like "VG_(foo)" and "vgPlain_foo" in assertion failure
messages. This is good since we actually want the "VG_(foo)" form used
in these messages.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3842
relying on any other modules -- in m_libcbase.
Also converted the 'size' parameters to functions like VG_(memcpy) and
VG_(strncpy) from Int to SizeT, as they should be.
Also removed VG_(atoll16) and VG_(toupper), which weren't being used.
Also made VG_(atoll36) less flexible -- it now only does base-36 numbers
instead of any base in the range 2..36, since base-36 is the only one we
need. As part of that, I fixed a horrible bug in it which caused it to
return incorrect answers for any number containing the digits 'A'..'I'!
(Eg. for "A; it would return 17 instead of 10!)
Had to disable the assertions in VG_(string_match), since this module can't
see vg_assert, which wasn't ideal but also isn't a disaster.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3838
sensible now -- no vg_dummy_profile.c, no silly #including of
vg_profile.c from tools.
Unfortunately, it still doesn't work, due to bad interactions
with signal handling that I don't understand.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3833
