__builtin_setjmp and __builtin_longjmp so that they can be selectively
replaced, on a platform by platform basis. Does not change any
functionality. Related to #259977.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11687
workload: when scanning a freelist of a given size for a big-enough
block (to allocate), don't scan all the way around the list. Instead
give up after 100 blocks and try the freelist above. The pathological
case (as observed) is that the freelist contains tens of thousands of
blocks, but all are too small for the current request, hence they are
all visited pointlessly. If the new heuristic is used, the freelist
start point is moved along by one block, so that future searches
eventually inspect the entire freelist, just very slowly.
Also, some improvements to stats gathering, and rename of some
existing stats fields in struct Arena.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11567
This commit tidies up and rationalises what could be called the
"messaging" system -- that part of V to do with presenting output to
the user. In particular it brings significant improvements to XML
output.
Changes are:
* XML and normal text output now have separate file descriptors,
which solves longstanding problems for XML consumers caused by
the XML output getting polluted by unexpected non-XML output.
* This also means that we no longer have to hardwire all manner
of output settings (verbosity, etc) when XML is requested.
* The XML output format has been revised, cleaned up, and made
more suitable for use by error detecting tools in general
(various Memcheck-specific features have been removed). XML
output is enabled for Ptrcheck and Helgrind, and Memcheck is
updated to the new format.
* One side effect is that the behaviour of VG_(message) has been
made to be consistent with printf: it no longer automatically
adds a newline at the end of the output. This means multiple
calls to it can be used to build up a single line message; or a
single call can write a multi-line message. The ==pid==
preamble is automatically inserted at each newline.
* VG_(message)(Vg_UserMsg, ..args..) now has the abbreviated form
VG_(UMSG)(..args..); ditto VG_(DMSG) for Vg_DebugMsg and
VG_(EMSG) for Vg_DebugExtraMsg. A couple of other useful
printf derivatives have been added to pub_tool_libcprint.h,
most particularly VG_(vcbprintf).
* There's a small change in the core-tool interface to do with
error handling: VG_(needs_tool_errors) has a new method
void (*before_pp_Error)(Error* err) which, if non-NULL, is
called just before void (*pp_Error)(Error* err). This is to
give tools the chance to look at errors before any part of them
is printed, so they can print any XML preamble they like.
* coregrind/m_errormgr.c has been overhauled and cleaned up, and
is a bit simpler and more commented. In particular pp_Error
and VG_(maybe_record_error) are significantly changed.
The diff is huge, but mostly very boring. Most of the changes
are of the form
- VG_(message)(Vg_UserMsg, "this is a message %d", n);
+ VG_(message)(Vg_UserMsg, "this is a message %d\n", n);
Unfortunately as a result of this, it touches a large number
of source files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10465
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876
caused by heap corruption by the client. Also clarified the FAQ about this.
Also updated the FAQ about decoding failures a little.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9556
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
