Re: gdb/2022: gdb hangs on command kill on Solaris10 edition 10/05

["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.