overhaul of the thread support. Many things are now probably broken,
but at least with --tool=none, simple and not-so-simple threaded and
non-thread programs work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3265
which list all the arches/OSes/platforms supported. These are used by
several newly added DIST_SUBDIRS automake commands, which specify that
although when you are building you only want to build for the current
arch/OS/platform, when you do 'make dist' you want every
arch/OS/platform to get included.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3127
While doing so, fixed bug #93328, by using the right sized types in
sigprocmask(), and converting them as necessary. Added a regression test for
it too.
(partly) MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3013
- All memory-related errors are now clear whether they are caused by
unaddressable or uninitialised memory. (Previously, writes were
clearly addressability errors, but reads could be either.) Mostly
done by replacing the 'isWrite' field in MAC_Error with 'isUnaddr'.
Also, mc_check_readable() now indicates not just if an error occurred,
but what kind of error (ie. addressability or definedness).
- Put machinery into place in the core to inform tools when registers
are being read by the core -- ie. a 'pre_reg_read' event. Most
notably, this facilitates syscall scalar arg definedness checking for
Memcheck. Currently this is only working for read(), write(), exit()
and exit_group(), but it will be extended as the syscalls are
overhauled as part of the arch-abstraction work.
A consequence of this is that the ParamErr messages have changed. This:
Syscall param write(buf) contains uninitialised byte(s)
now means that the pointer 'buf' is partially undefined. If the memory
pointed to by 'buf' is partially undefined or unaddressable, it says one of:
Syscall param write(buf) points to uninitialised byte(s)
Syscall param write(buf) points to unaddressable byte(s)
The docs have been updated accordingly.
I also added a couple of regression tests.
These two change sare notable for being the first improvements to
Memcheck's checking/errors in a long time.
I also folded mc_clientreqs.c into mc_main.c, which saves exporting a
whole bunch of things that are not used anywhere else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2949
- Moved all the insn_* tests into x86/ subdirectories. What are the chances of
me getting this right on the first attempt?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2809
of using an assembly hack to find the stack pointer at startup, we find it from
argv. It's much simpler, avoids linking games, is platform independent, and
works on PPC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2782
Valgrind itself (the files ume.c, ume_entry.c and jmp_with_stack.c). Thus,
we are using Memcheck to check these files in a unit test setting.
I hope to do unit self-testing for many more parts of Valgrind, eventually all
the bits that can be pulled out into any kind of sensible stand-alone form.
Doing so achieves two things:
a) it introduces unit testing into our framework (a serious shortcoming at the
moment)
b) it lets us use Valgrind (esp. Memcheck) on itself, to some extent
This should help reliability. This first unit self-test isn't very exhaustive,
but it's a start.
Note that this involves something like bootstrapping, in that we are checking
parts of a Valgrind build with itself. I don't think this will be a problem,
since we (at least, I do) tend to only run the regtests when we think the
Valgrind build is ok.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2760
signal handler present -- previously, Valgrind would abort unnecessarily on
this case.
Added a regression test for it.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2743
lots of the details changed. Made the following generalisations:
- Recast everything to be entirely terms of bytes, instead of a mixture
of (32-bit) words and bytes. This is a bit easier to understand, and
made the following generalisations possible...
- Almost 64-bit clean; no longer assuming 32-bit words/pointers. Only
(I think) non-64-bit clean part is that VG_(malloc)() et al take an
Int as the size arg, and size_t is 64-bits on 64-bit machines.
- Made the alignment of blocks returned by malloc() et al completely
controlled by a single value, VG_MIN_MALLOC_SZB. (Previously there
were various magic numbers and assumptions about block alignment
scattered throughout.) I tested this, all the regression tests pass
with VG_MIN_MALLOC_SZB of 4, 8, 16, 32, 64. One thing required for
this was to make redzones elastic; the asked-for redzone size is now
the minimum size; it will use bigger ones if necessary to get the
required alignment.
Some other specific changes:
- Made use of types a bit more; ie. actually using the type 'Block',
rather than just having everything as arrays of words, so that should
be a bit safer.
- Removed the a->rz_check field, which was redundant wrt. a->clientmem.
- Fixed up the decision about which list to use so the 4 lists which
weren't ever being used now are -- the problem was that this hasn't
been properly updated when alignment changed from 4 to 8 bytes.
- Added a regression test for memalign() and posix_memalign().
memalign() was aborting if passed a bad alignment argument.
- Added some high-level comments in various places, explaining how the
damn thing works.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2579
(fewer) functions.
Also fixed execve() so that it works better with .in_place.
Also added a regression test for --trace-children=yes (there were none!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2577
Problem was that the malloc-replacing tools (memcheck, addrcheck, massif,
helgrind) would assert if a too-big malloc was attempted. Now they return 0 to
the client. I also cleaned up the code handling heap-block-metadata in Massif
and Addrcheck/Memcheck a little.
This exposed a nasty bug in VG_(client_alloc)() which wasn't checking if
find_map_space() was succeeding before attempting an mmap(). Before I added
the check, very big mallocs (eg 2GB) for Addrcheck were overwriting the client
space at address 0 and causing crashes.
Added a regtest to all the affected skins for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2462
look at whether the eflags are read or written and generate UCode to validate
and/or mark as valid the eflags when necessary.
CCMAIL: 78514-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2344
they rely on this area being unmapped for their quick sanity check. This
commit make Valgrind refuse to mmap() this area. Added a regtest for it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2085
don't just call the unmangled versions, but do the appropriate stuff
themselves directly (this was necessary for Massif). This means that stack
traces for them have one fewer function. And I was able to gather up several
very similar functions into a macro, reducing the amount of code, which was
nice. Had to update one regtest's expected output accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1875
was just saying "invalid memory access").
Added a regression test for this, for memcheck and addrcheck. Also made
Addrcheck use Memcheck's fprw regtest. Was able to remove the not-very-useful
'true' test for Addrcheck now that it has a couple of real tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1815
count. Added a regression test for it.
Updated the basic test stderr filter to strip out line numbers from
vg_intercept.c
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1812
Previously, when realloc() was asked to make a block bigger, the ExeContext
describing where that block was allocated was increased; however, if the block
became smaller or stayed the same size, the original ExeContext remained. This
is correct in one way (that's where the memory manager actually parcelled out
the block) but it's not very intuitive. This commit changes things so the
ExeContext of a block is always changed upon realloc(). I added a regression
test for it too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1783
CPUID.
Also added filters to Makefiles where missing; "make regtest" was broken
within distributions created using "make dist", now fixed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1709
- changed deprecated INCLUDES variable to AM_CPPFLAGS
- moved the -DVG_LIBDIR definition from AM_CFLAGS into AM_CPPFLAGS
- generally neatened them up a bit -- removed old commented out stuff, fixed a
couple of other minor things
Everything works for me, hopefully it won't break things for anyone else...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1680
use a custom-allocator and detect almost as many errors as you could detect if
you used malloc/new/new[]. (eg. leaks detected, free errors, free mismatch,
etc).
Had to fiddle with mac_malloc_wrappers.c a bit to factor out the appropriate
code to be called from the client request handling code. Also had to add a
new element `MAC_AllocCustom' to the MAC_AllocKind type.
Also added a little documentation, and a regression test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1643
