routine, to the routine in our trampoline page so that the
special sysinfo unwind hack in vg_execontext.c will kick in.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2334
client code (in vg_libpthread.c) to set the appropriate signal mask when
its ready. This prevents a bug where a thread gets sent a signal before
even running any of its initialization code, which can cause problems
(particularly if the signal handler directly or indirectly uses TLS).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2332
VG_(synth_fault_*), which synthesize faults as if an instruction had
caused a CPU fault. This is used in two places: one in vg_translate.c,
when trying to fetch instructions from bad memory, and the other in
vg_ldt.c, when using a bad segment register. This fixes a bug where an
assertion would fail rather than getting a useful message.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2324
basically by messing with the block layout.
* Move freelist next ptr from before payload to after it
* Ensure payload and red zones always have sizes which are
multiples of 8-bytes.
Seems to work OK. Values returned from the two basic allocator
functions VG_(arena_malloc) and VG_(arena_malloc_aligned) are
vg_asserted to have suitable alignment (== 8, >= 8 && == requested
alignment) respectively.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2316
that when the client is killed by a coredumping signal, Valgrind will
generate the coredump itself, which is full of client state, rather than
Valgrind state; this core file will therefore be useful to the developer
in debugging their program.
The corefile generated is named vgcore.pidNNNNN (and maybe with .M on
the end in case of duplicates). If you set a logfile with --logfile,
then this name will be used as the basename for the core file, so that
both the core and the logs will be next to each other.
Valgrind respects the RLIMIT_CORE limit when generating the file; if the
limit is set to 0, then it will not generate one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2312
being able to use malloc as the libc malloc tries to use thread specific
data and we wind up in a recursive nightmare.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2293
The problem is that the use of VG_(system) causes a SIGCHLD to be sent
to the process, which ends up being delivered to one of the proxy LWPs
(which is a small problem in itself, but nothing too bad).
The proxy tells the scheduler LWP about this, and the scheduler LWP sends
a sigACK reply.
Then, while the proxy LWP is in the SigACK state, and the SigACK reply
is still queued in the message pipe, the scheduler LWP starts shutting
Valgrind down, and sends a SIGVGKILL to all proxy LWPs. This causes
the proxy to drop from sigACK state to WaitReq state, and it reads
further commands - one of which is the SigACK message - this causes the
assertion failure.
The fix is to simply make the proxy LWP exit immediately when it gets
a SIGVGKILL, and not process any more requests.
This change also fixes a bug in VG_(system), in which the child process
returns back into Valgrind rather than exiting when exec fails.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2284
2.3.3, which is binary-compatible, but not source compatible with the old one,
which came from LinuxThreads. We were using the types defined in the old one,
which caused compilation errors on systems using the new one.
This commit introduces our own versions of these types. Our versions are laid
out identically to the LinuxThreads ones, but the field names are different.
We convert all pthread types to our versions before using them, so we don't
rely on the pthreadtypes.h types any more. Hopefully this will fix the
problem; I have three reports that it does. Let's see...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2272
recvmsg() where I'm not sure if it should be checked, and if so, what error
should be returned if the check fails.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2268
"foo<bar::blat>"; normally stabs names are terminated by ':', but we
also need to keep track of <> pairs so we can ignore nested colons.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2267
segment to be moved up to stage2's brk segment. Instead, Valgrind's
use of brk is simulated with mmap. In order to prevent any unwanted use
of the process brk segment, it also sets the RLIMIT_DATA to 0, which will
make brk always fail. glibc's malloc will use mmap to allocate if brk
fails. We try to intercept glibc's brk, but malloc seems to always use the
library-internal version. (The client's use of brk has always been simulated,
and is unaffected by this change.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2266
Patch to ignore REP prefixes on single byte RET instructions.
(REP RET is apparently faster than RET on AMD K7/K8)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2257
limit for file descriptors to try and prevent the target programming realising
that the reserved file descriptors exist. It also appears to fix
sysconf(_SC_OPEN_MAX) so that must be going through the same system call.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2250
This patch adds translation tests for most of the basic x86 instructions and
fixes a few missing/broken instructions to work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2242
scopes and out of order line number information in the stabs debug info.
I wonder if this is the stabs writer rotting now that dwarf is the
default...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2240
Doesn't fix "make distcheck", however, because this happens:
/usr/bin/ld: cannot open linker script file ../../coregrind/x86/stage2.lds:
No such file or directory
For some reason I can't work out, that file is built when you make in a CVS
tree, or manually from a "make dist" tarball, but not when you "make
distcheck".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2239
