mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-28 12:33:36 +08:00
a65f68357f
Running the gdb testsuite under Valgrind started to fail after 100+ tests, due to out of memory caused by lingering processes. The lingering processes are caused by the combination of a limitation in Valgrind signal handling when using PTRACE_TRACEME and a (minor) bug in GDB. The Valgrind limitation is : when a process is ptraced and raises a signal, Valgrind will replace the raised signal by SIGSTOP as other signals are masked by Valgrind when executing a system call. Removing this limitation seems far to be trivial, valgrind signal handling is very complex. Due to this valgrind limitation, GDB linux_ptrace_test_ret_to_nx gets a SIGSTOP signal instead of the expected SIGTRAP or SIGSEGV. In such a case, linux_ptrace_test_ret_to_nx does an early return, but does not kill the child (running under valgrind), child stays in a STOP-ped state. These lingering processes then eat the available system memory, till launching a new process starts to fail. This patch fixes the GDB minor bug by killing the child in case linux_ptrace_test_ret_to_nx does an early return. nat/linux-ptrace.c has 3 different logics to kill a child process. So, this patch factorizes killing a child in the function kill_child. The 3 different logics are: * linux_ptrace_test_ret_to_nx is calling both kill (child, SIGKILL) and ptrace (PTRACE_KILL, child, ...), and then is calling once waitpid. * linux_check_ptrace_features is calling ptrace (PTRACE_KILL, child, ...) + my_waitpid in a loop, as long as the waitpid status was WIFSTOPPED. * linux_test_for_tracefork is calling once ptrace (PTRACE_KILL, child, ...) + my_waitpid. The linux ptrace documentation indicates that PTRACE_KILL is deprecated, and tells to not use it, as it might return success but not kill the tracee. The documentation indicates to send SIGKILL directly. I suspect that linux_ptrace_test_ret_to_nx calls both kill and ptrace just to be sure ... I suspect that linux_check_ptrace_features calls ptrace in a loop to bypass the PTRACE_KILL limitation. And it looks like linux_test_for_tracefork does not handle the PTRACE_KILL limitation. Also, 2 of the 3 logics are calling my_waitpid, which seems better, as this is protecting the waitpid syscall against EINTR. So, the logic in kill_child is just using kill (child, SIGKILL) + my_waitpid, and then does a few verifications to see everything worked accordingly to the plan. Tested on Debian/x86_64. 2018-12-16 Philippe Waroquiers <philippe.waroquiers@skynet.be> * nat/linux-ptrace.c (kill_child): New function. (linux_ptrace_test_ret_to_nx): Use kill_child instead of local code. Add a call to kill_child in case of early return after fork. (linux_check_ptrace_features): Use kill_child instead of local code. (linux_test_for_tracefork): Likewise. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.