linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* NPTL: Parent thread receives SIGHUP when child thread terminates?
@ 2004-10-21 10:13 Petr Vandrovec
  2004-10-21 23:10 ` Ulrich Drepper
  2004-10-22 11:01 ` Roland McGrath
  0 siblings, 2 replies; 3+ messages in thread
From: Petr Vandrovec @ 2004-10-21 10:13 UTC (permalink / raw)
  To: linux-kernel

Hello,
  one friend noticed that multithreaded programs (VMware...) behave erraticaly 
when started from rxvt or xterm with -e option.  We've traced it down to some 
strange SIGHUP delivery.

  When process is session leader, is it supposed to receive SIGHUP when child
thread terminates?  It did not receive SIGHUP under non-NPTL library, and IMHO
it was correct behavior.  Now all exiting threads cause SIGHUP to be delivered
to the parent, and parent (I'd say correctly) assumes that connection to the
program was broken and terminates.

  Probably disassociate_ctty(1) in do_exit() should not be invoked for all
tsk->signal->leader, but only for those with thread_group_empty() == 1, i.e.
when this process is really going away ?  Or only for thread group leader?

					Thanks,
						Petr Vandrovec




/* Build with:
gcc -W -Wall -O2 -o testhup testhup.c -lpthread -lutil

vana:~# ./testhup
Got SIGHUP!
vana:~# LD_ASSUME_KERNEL=2.4.1 ./testhup
vana:~#

*/

#include <pthread.h>
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <fcntl.h>
#include <pty.h>
#include <stdlib.h>
#include <sys/wait.h>

static void sighup(int sig) {
	printf("Got SIGHUP!\n");
}

static void* child(void* arg) {
	return arg;
}

int main(void) {
	int master, slave;
	char name[100];

	openpty(&master, &slave, name, NULL, NULL);
	if (fork() == 0) {
		pthread_t pth;

		signal(SIGHUP, sighup);

		/* Become session leader. */
		if (setsid() == -1) {
			perror("SetSID");
			exit(1);
		}
		/* Assign controlling terminal. */
		if (open(name, O_RDWR) == -1) {
			perror("Open PTY");
			exit(2);
		}

		/* In reality code above is xterm/rxvt, code below is an
                 * innocent MT application execed by xterm/rxvt */

		/* Die with SIGHUP after child thread terminates. */
		pthread_create(&pth, NULL, child, NULL);
		pthread_join(pth, NULL);
		exit(3);
	} else {
		wait(NULL);
	}
	return 0;
}


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: NPTL: Parent thread receives SIGHUP when child thread terminates?
  2004-10-21 10:13 NPTL: Parent thread receives SIGHUP when child thread terminates? Petr Vandrovec
@ 2004-10-21 23:10 ` Ulrich Drepper
  2004-10-22 11:01 ` Roland McGrath
  1 sibling, 0 replies; 3+ messages in thread
From: Ulrich Drepper @ 2004-10-21 23:10 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petr Vandrovec wrote:

>   When process is session leader, is it supposed to receive SIGHUP when child
> thread terminates?

No, it's not.  I hope somebody knowing the signal code will look at
this.  I've forwarded the mail to Roland.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBeEHt2ijCOnn/RHQRAsSmAJ9RXjR71D/rLDEG2IxKt5++VYfRGACdELgM
uxry9CwYy5/j/a2dHGyKdX0=
=V+53
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: NPTL: Parent thread receives SIGHUP when child thread terminates?
  2004-10-21 10:13 NPTL: Parent thread receives SIGHUP when child thread terminates? Petr Vandrovec
  2004-10-21 23:10 ` Ulrich Drepper
@ 2004-10-22 11:01 ` Roland McGrath
  1 sibling, 0 replies; 3+ messages in thread
From: Roland McGrath @ 2004-10-22 11:01 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: linux-kernel

>   When process is session leader, is it supposed to receive SIGHUP when child
> thread terminates?

Nope, this is certainly wrong.

>   Probably disassociate_ctty(1) in do_exit() should not be invoked for all
> tsk->signal->leader, but only for those with thread_group_empty() == 1, i.e.
> when this process is really going away ?  Or only for thread group leader?

Indeed, but that particular kind of test is subject to race conditions.  I
think the easiest way to fix this is to use the bookkeeping I added to get
process accounting correct (another thing that has to happen on the last
thread's death).  Start with this patch:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/broken-out/acct-report-single-record-for-multithreaded-process.patch


Then throw this one on top.


Thanks,
Roland


---

The session leader should disassociate from its controlling terminal and
send SIGHUP signals only when the whole session leader process dies.
Currently, this gets done when any thread in that process dies, which is
wrong.  This patch fixes it.  


Signed-off-by: Roland McGrath <roland@redhat.com>

--- linux-2.6/kernel/exit.c.acct
+++ linux-2.6/kernel/exit.c
@@ -783,6 +783,7 @@ static void exit_notify(struct task_stru
 asmlinkage NORET_TYPE void do_exit(long code)
 {
 	struct task_struct *tsk = current;
+	int group_dead;
 
 	profile_task_exit(tsk);
 
@@ -807,7 +808,8 @@ asmlinkage NORET_TYPE void do_exit(long 
 		ptrace_notify((PTRACE_EVENT_EXIT << 8) | SIGTRAP);
 	}
 
-	if (atomic_dec_and_test(&tsk->signal->live))
+	group_dead = atomic_dec_and_test(&tsk->signal->live);
+	if (group_dead)
 		acct_process(code);
 	__exit_mm(tsk);
 
@@ -818,7 +820,7 @@ asmlinkage NORET_TYPE void do_exit(long 
 	exit_thread();
 	exit_keys(tsk);
 
-	if (tsk->signal->leader)
+	if (group_dead && tsk->signal->leader)
 		disassociate_ctty(1);
 
 	module_put(tsk->thread_info->exec_domain->module);

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-10-22 11:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-21 10:13 NPTL: Parent thread receives SIGHUP when child thread terminates? Petr Vandrovec
2004-10-21 23:10 ` Ulrich Drepper
2004-10-22 11:01 ` Roland McGrath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).