From 9d67cc59c462f8321b41ee8ec9155d88b6ec1b6b Mon Sep 17 00:00:00 2001 From: Jim Ingham Date: Fri, 21 Feb 2014 22:35:29 +0000 Subject: We have to call waitpid on the lldb side for Mac OS X (even though we've successfully called it on the debugserver side) when we kill a process or it leaves a zombie around. llvm-svn: 201896 --- .../Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'lldb/source/Plugins/Process/gdb-remote') 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(); -- cgit v1.2.3