a signal handler when VDSOs are turned off in FC2. Note that we don't
(yet) support VDSOs being on (use "echo 0 > /proc/sys/kernel/vdso").
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2400
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
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
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
threads to have thread-private data which is quickly accessible via a
segment in the GDT, stored in %gs. The patch implements the relevent
syscalls (setthreadarea), and also manages switching the VCPU's segment
information at thread context-switch time. Mostly Tom Hughes' work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2215
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
If the proxyLWP for a thread got a signal just as we were sending the
syscall request to it, then we would end up running the syscall twice.
The fix is to not check the results pipe while sending the syscall request
- wait until we're in a better state for handling signals (the deadlock
the results-read was supposed to avoid cannot actually happen).
Related to that, if we're delivering a signal to a thread, and that thread
is currently waiting for a syscall to complete, make sure we collect the
syscall results before entering the signal handler (otherwise we may end
up bogusly trying to restart the syscall by moving EIP back, even though
it now points to the signal handler rather than the syscall instruction)
This change also adds an assertion to VG_(restart_syscall) to make sure
we were actually restarting a syscall and not just randomly changing EIP
(this found the problem above).
Also, make set/getitimer run in the proxyLWP context, so that they
modify/read the proxyLWP's timers rather than the schedluer LWP's timers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2013
- restart syscalls which return ERESETARTSYS
- make code to restart a syscall common
- keep a process-wide pending signal set to store as-yet
undelivered signals (only used in 2.4 mode; TODO: siginfo, queues)
- make execve work a bit better - it is impossible to recover from
execve failing, so we try to check that it will before running the
syscall itself (also fixes bug with SuSE 8.2 kernel)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1964
a logfile for that pid already exists. This may happen for programs
started during system boot which will tend to get the same pid each boot.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1928
with the aim of making it more robust, more correct and perhaps faster.
This patch removes the need to poll blocking syscalls, by adding a proxy
LWP for each application thread. This LWP is a kernel thread whose job
is to run all (potentially) blocking syscalls, and also to handle signals.
This allows the kernel to do more of the work of dealing with signals,
so on kernels which do this properly (2.6), Valgrind's behavious is a
lot more posix compliant. On base 2.4 kernels, we emulate some of the
missing 2.6 functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1918
