Commit: 1584354913285389063622a39f845851f332eb9a - binutils_os216 (git)

GNU Binutils with patches for OS216

Commit MetaInfo

• Revision: 1584354913285389063622a39f845851f332eb9a (tree)
• Time: 2018-08-03 06:08:45
• Author: Xavier Roirand <roirand@adac...>
• Commiter: Tom Tromey

Log Message

Fix kill issue leading to zombie process on MacOS Sierra

Starting with MacOS version Sierra, the gdb kill command
seems to work but inferior remains as zombie on the host.
Notice that, as zombie process, the inferior is not killable
by the user, nor by root.

The kill signal gdb sent to the inferior is not handled
in gdb as a signal sent by gdb thus no reply is made and
the process remains (since MacOS does not "release" the
inferior because no reply have been made to the signal
message).

This patch fixes this problem.

gdb/ChangeLog
2018-08-02 Xavier Roirand <[e-mail]>

PR gdb/22629:

• • • • darwin-nat.c (darwin_kill_inferior): Fix handling of
        kill inferior.
        

Change Summary

• modified: gdb/ChangeLog
• modified: gdb/darwin-nat.c

Incremental Difference

--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
[phone]  Xavier Roirand  <[e-mail]>
+
+	PR gdb/22629:
+        * darwin-nat.c (darwin_kill_inferior): Fix handling of
+        kill inferior.
+
 2018-08-02  Tom Tromey  <[e-mail]>
 
 	* darwin-nat.c (find_inferior_task_it, darwin_find_thread)

--- a/gdb/darwin-nat.c
+++ b/gdb/darwin-nat.c
@@ -1549,6 +1549,24 @@ darwin_nat_target::kill ()
 
   if (res == 0)
     {
+      /* On MacOS version Sierra, the darwin_restore_exception_ports call
+         does not work as expected.
+         When the kill function is called, the SIGKILL signal is received
+         by gdb whereas it should have been received by the kernel since
+         the exception ports have been restored.
+         This behavior is not the expected one thus gdb does not reply to
+         the received SIGKILL message. This situation leads to a "busy"
+         resource from the kernel point of view and the inferior is never
+         released, causing it to remain as a zombie process, even after
+	 GDB exits.
+         To work around this, we mark all the threads of the inferior as
+         signaled thus darwin_decode_message function knows that the kill
+         signal was sent by gdb and will take the appropriate action
+         (cancel signal and reply to the signal message).  */
+      darwin_inferior *priv = get_darwin_inferior (inf);
+      for (darwin_thread_t *thread : priv->threads)
+        thread->signaled = 1;
+
       darwin_resume_inferior (inf);
 
       ptid = darwin_wait (inferior_ptid, &wstatus);