All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Ptrace updates: has_stopped_jobs [1/5]
Date: Thu, 6 Feb 2003 17:40:47 -0500	[thread overview]
Message-ID: <20030206224047.GA22762@nevyn.them.org> (raw)
In-Reply-To: <20030206223924.GA22688@nevyn.them.org>

I posted this patch a couple of weeks ago, here it is again.  The basic
problem it's solving is this: suppose you have GDB debugging an application,
using the new PTRACE_EVENT_FORK.  The application forks.  There can be a
point where GDB resumes the parent, which gets scheduled, and exits, before
GDB gets a chance to resume the child.  has_stopped_jobs causes the kernel
to decide the still-stopped-in-GDB child (which will be an orphaned pgrp) is
going to be lost, so it sends a SIGHUP and SIGCONT to it, confusing GDB
terribly.  Normally those signals wouldn't be sent.


The longer explanation:

POSIX has this terribly useful thing to say:

# If the exit of the process causes a process group to become orphaned, and if
# any member of the newly-orphaned process group is stopped, then a SIGHUP
# signal followed by a SIGCONT signal shall be sent to each process in the
# newly-orphaned process group.

The Rationale is at least a little chattier.  See

http://www.opengroup.org/onlinepubs/007904975/functions/exit.html#tag_03_131  
if you want to read it.

Basically, this is so that a stopped process group won't unintentionally
stay stopped when its shell no longer has a connection to it.  For whatever
that's worth.

I think this patch is well within the spirit of that definition.  If a
process is stopped, but there is a debugger attached to it and the stopping
signal is not one that would normally stop the process, then don't count it
as a stopped job.  Without this, when you continue past a fork() call and
the parent quickly exits, the child will get an unaccountable SIGHUP.

It's not perfect, of course - the application might be SIG_IGN'ing SIGTSTP,
but stopped in the debugger for it anyway.  It's not worth being that
complicated here, though.


# --------------------------------------------
# 03/01/18	drow@nevyn.them.org	1.957
# Tweak has_stopped_jobs for use with debugging
# --------------------------------------------

diff -Nru a/kernel/exit.c b/kernel/exit.c
--- a/kernel/exit.c	Thu Feb  6 16:57:39 2003
+++ b/kernel/exit.c	Thu Feb  6 16:57:39 2003
@@ -203,6 +203,17 @@
 	for_each_task_pid(pgrp, PIDTYPE_PGID, p, l, pid) {
 		if (p->state != TASK_STOPPED)
 			continue;
+
+		/* If p is stopped by a debugger on a signal that won't
+		   stop it, then don't count p as stopped.  This isn't
+		   perfect but it's a good approximation.  */
+		if (unlikely (p->ptrace)
+		    && p->exit_code != SIGSTOP
+		    && p->exit_code != SIGTSTP
+		    && p->exit_code != SIGTTOU
+		    && p->exit_code != SIGTTIN)
+			continue;
+
 		retval = 1;
 		break;
 	}

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2003-02-06 22:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-06 22:39 Ptrace updates [0/5] Daniel Jacobowitz
2003-02-06 22:40 ` Daniel Jacobowitz [this message]
2003-02-06 22:41 ` Ptrace updates: PTRACE_GETSIGINFO [2/5] Daniel Jacobowitz
2003-02-06 22:42 ` Ptrace updates: CLONE_PTRACE should use force_sig_specific [3/5] Daniel Jacobowitz
2003-02-06 22:42 ` Ptrace updates: event tracing for vfork finish and process exit [4/5] Daniel Jacobowitz
2003-02-06 22:43 ` Ptrace updates: Prevent zombies when debugging LinuxThreads apps [5/5] Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030206224047.GA22762@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.