This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: gdb/2022: gdb hangs on command kill on Solaris10 edition 10/05
- From: "Steve Williams" <steve dot williams at utstar dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 4 Nov 2005 00:48:01 -0000
- Subject: Re: gdb/2022: gdb hangs on command kill on Solaris10 edition 10/05
- Reply-to: "Steve Williams" <steve dot williams at utstar dot com>
The following reply was made to PR gdb/2022; it has been noted by GNATS.
From: "Steve Williams" <steve.williams@utstar.com>
To: <gdb-gnats@sources.redhat.com>
Cc:
Subject: Re: gdb/2022: gdb hangs on command kill on Solaris10 edition 10/05
Date: Thu, 3 Nov 2005 16:45:36 -0800
The following patch seems to fix the inferior hanging around when gdb quits
or the kill command is issued. I just make the thread runnable before the
kill signal is delivered.
--- gdb-6.3/gdb/procfs.c 2004-10-08 13:29:47.000000000 -0700
+++ gdb-6.3.p/gdb/procfs.c 2005-10-28 15:42:35.614962000 -0700
@@ -4736,6 +4736,12 @@
ioctl (pi->ctl_fd, PIOCSSIG, &newsiginfo);
}
#else /* PROCFS_NEED_PIOCSSIG_FOR_KILL */
+ if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP))
+ {
+ if (!proc_run_process (pi, 0, 0))
+ proc_error (pi, "make_signal_thread_runnable", __LINE__);
+ return 1;
+ }
if (!proc_kill (pi, SIGKILL))
proc_error (pi, "unconditionally_kill, proc_kill", __LINE__); #endif
/* PROCFS_NEED_PIOCSSIG_FOR_KILL */
This does not fix the problem when gdb is killed. As far as I can tell this
problem always existed. If you kill gdb, the inferior is not killed.
I notice the problem now because when the testsuite is run, 20 or 30
orphaned inferiors are left running after the test, consuming all CPU cycles
between them. I believe the problem lies in the interaction between dejagnu
and gdb, but only on this new edition of Solaris10, i.e. I can't repeat it
on an older version of Solaris or the original Solaris10 release.
Dejagnu terminates the gdb process by sending a kill to the process group
(in remote.exp line 321), in older versions of Solaris, this seemed to
terminate the inferior also (even though it is in its own process group).
Now it doesn't, the inferior remains running.
Shouldn't gdb catch QUIT, HUP and TERM signals and pass them to the inferior
as well, currently it seems only QUIT and HUP are caught, but these get
queued if the inferior is running, and TERM is set to default, so only gdb
terminates when it receives a TERM signal.