diff options
| -rw-r--r-- | lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp index f9a5b06abb0..5e3ba3f19ef 100644 --- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp +++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp @@ -2022,6 +2022,24 @@ ProcessGDBRemote::DoDestroy () if (packet_cmd == 'W' || packet_cmd == 'X') { +#if 0 && defined(__APPLE__) + // For Native processes on Mac OS X, we launch through the Host Platform, then hand the process off + // to debugserver, which becomes the parent process through "PT_ATTACH". Then when we go to kill + // the process on Mac OS X we call ptrace(PT_KILL) to kill it, then we call waitpid which returns + // with no error and the correct status. But amusingly enough that doesn't seem to actually reap + // the process, but instead it is left around as a Zombie. Probably the kernel is in the process of + // switching ownership back to lldb which was the original parent, and gets confused in the handoff. + // Anyway, so call waitpid here to finally reap it. + PlatformSP platform_sp(GetTarget().GetPlatform()); + if (platform_sp && platform_sp->IsHost()) + { + int status; + ::pid_t reap_pid; + reap_pid = waitpid (GetID(), &status, WNOHANG); + if (log) + log->Printf ("Reaped pid: %d, status: %d.\n", reap_pid, status); + } +#endif SetLastStopPacket (response); ClearThreadIDList (); exit_status = response.GetHexU8(); |
