Xcode leaving zombie processes after running iOS tests/simulator

Question

After working in Xcode on an iOS app for a few days, I've noticed that there are over 100 zombie processes hanging around. It appears that there is one for each time that I ran unit tests, and possibly one for each time I ran the full app in the simulator. Here's a sample (cleaned and truncated):

> ps -efj | grep $PRODUCT_NAME
  502  2794   236   0 Wed12AM ??         0:00.00 (MyProduct)  me            2794      0    1 Z      ?? 
  502  2843   236   0 Wed01AM ??         0:00.00 (MyProduct)  me            2843      0    1 Z      ?? 
  502  2886   236   0 Wed01AM ??         0:00.00 (MyProduct)  me            2886      0    1 Z      ?? 
...
  502 13711   236   0 Thu11PM ??         0:00.00 (MyProduct)  me           13711      0    1 Z      ?? 
  502 13770   236   0 Thu11PM ??         0:00.00 (MyProduct)  me           13770      0    1 Z      ?? 
  502 14219   236   0 10:35AM ??         0:00.00 (MyProduct)  me           14219      0    1 Z      ?? 
  502 14280   236   0 10:38AM ??         0:00.00 (MyProduct)  me           14280      0    1 Z      ?? 

The Z in the second to last column indicates they are zombie processes. The 236 in the third column is the parent PID, which belongs to my user's launchd in this case.

Note that some of the processes are multiple days old. I have quit and reopened Xcode a few times during this time period.

Does anyone know why this happens, or whether this should be cause for alarm?

Rambouillet

I have 437 Zombies and counting. The only problem that will happen sooner or later is that you can't start any new processes, so keep the zombies in mind. Took me a while to figure out why I couldn't compile any more. Also see https://mcmap.net/q/35626/-error-when-testing-on-ios-simulator-couldn-39-t-register-with-the-bootstrap-server – Dutcher

@esker Did you ever figure out a resolution for this aside from rebooting? – Precess

No, as far as I understand, that’s just how it works. See the discussion below about the zombie processes ending up belonging to launchd. It appears that the only potential problem could be running out of pids after a while. – Rambouillet

This problem is fixed in Xcode 4.6.3. – Borroff

possible duplicate of Zombie Processes from iPhone Simulator? – Borroff

This is older than the suggested duplicate, so should the other question instead be marked as a duplicate of this one? – Rambouillet

Answer 1

They don't particularly take up a lot of room.

This appears to be an artifact of the Xcode machinery improperly killing the subprocesses.

I have the same problem, but I note that the zombies belong to, in my case, ppid 271 which is an invocation of launchd under my name, instead the whole system.

I'm curious as to what might happen if I kill or hup that process.

In any case, logging out will probably clear the zombies. And certainly rebooting will, but thats to be avoided, in my book.

---

Oh, that went quite poorly. Don't kill your launchd, it unceremoniously kills your session, but does nothing to let you get it back, like give you a login screen.

I shall have to look and see of I left the zombies behind because of stopping Xcode. It seems like there might be a couple of dumb things here. It your process doesn't wait for a child, it gets zombied. If the parent dies, the next thing up the line gets it, I think, which in this case is launchd. Launchd ought to wait() for it, but maybe thats getting confused?

Yaupon

They don't particularly take up a lot of room. True except it takes something more important: eats the number of processes you can create. fork will fail so you cannot event exec kill – Moxa

@Moxa is completely right, after a few days without rebooting my dev system, I get this fork error all the time. – Asafoetida

@Moxa is right, after a couple of days without rebooting, I get the fork error frequently. Having to reboot is very annoying. Any other fix/workaround that doesn't involve increasing the amount of allowed processes? – Asafoetida

Actually you can log back after having killed launchd. You have to hit the shortcut shift-option-command-Q to "log-out" once you killed launchd. – Whipcord

I never remember that key sequence. Thanks, I'll try it out the next time, if I remember. :) – Yaupon

Answer 2

After some particularly heavy Xcode sessions where my MBP sounded like it was being asked to execute the STARNET Init Procedure, I decided to spend a few minutes looking into this zombie process nonsense... after all, a Unix box that can't fork is a useless Unix box. I may have some good news. Hopefully, we'll see. Running Xcode 4.6 on 10.8.2 here.

The zombie issue appears to happen regardless of GDB or LLDB usage. The app running within the simulator is owned by the debug process -- either GDB, or "debugserver" in the case of LLDB. When you hit "Stop" the app process running in the simulator goes zombie. This sounds like an unclean shutdown sequence.

On a hunch rather than hitting "Stop", I paused the app, and in the debug console (LLDB in my case) I unattached from the running app using "process detach". A quick ps verifies debugserver is no longer running... so far so good! Now, the app is still running in the simulator itself, just not under debug. In fact, hitting the Stop button now is a no-op.

In the simulator hit the home button to get back to springboard, then double-click the home button and manually close the app. Go to your command line and look for the zombie... no zombie! Yay.

So... next step is to see if there's a reasonable way to execute this or similar shutdown procedure via python script etc. 'Course that doesn't help if you're on GDB. If I can do a clean shutdown via a single debug console command then it's just a matter of getting used to not hitting the broken Stop button. Maybe there's a resource hack to disable it altogether... :)

EDIT #1: couple of interesting tidbits...

1.) Hitting Stop button in xcode just outright kills the debug and app processes -- there's no attempt to do a clean shutdown whatsoever. Printf debug in app delegate applicationWillTerminate and applicationDidEnterBackground shows that the running app is killed with prejudice -- no NSLogs shown in the console.

2.) In debug console calling [UIApplication terminateWithSuccess] will cause the app to terminate "properly", but still leaves a zombie... interestingly if you have a breakpoint set, the app won't terminate:

(lldb) expression
Enter expressions, then terminate with an empty line to evaluate:
[(UIApplication *)[UIApplication sharedApplication] terminateWithSuccess]

error: Execution was interrupted, reason: breakpoint 2.1.
The process has been returned to the state before execution.
(lldb) breakpoint disable 2.1
1 breakpoints disabled.
(lldb) expression
Enter expressions, then terminate with an empty line to evaluate:
[(UIApplication *)[UIApplication sharedApplication] terminateWithSuccess]

2013-03-25 01:28:00.186 iPhone Testbed[9481:c07] -[AppDelegate applicationWillTerminate:]
(lldb) 

So app goes through some sort of shutdown process, and the will terminate shows in console, but we still have a zombie, so it's still not a clean shutdown.

I'm thinking this whole thing has to do with the app going to the background within iOS runtime. When munging processes directly (via Stop button, kill command, debug console stuff, etc. etc.) iOS runtime is not allowed to do proper shutdown and cleanup -- in fact, springboard still thinks the app is running in the background even when the process no longer exists. It just so happens our iOS and OS X runtimes are one in the same -- hence launchd owning the zombie.

So I think the solution to all of this is determining a clean shutdown procedure at the iOS level and at least be able to execute that via debug console. Gonna look more into UIApplicationExitsOnSuspend flag, see if I can set the necessary bits at runtime (as opposed to plist) to get the app shutdown cleanly upon debug detach...

Josphinejoss

Very interesting answer. So far the most complete I've ever saw on this subject. Looking forward to any development! – Whipcord

Thanks for the details. Would it make sense for launchd to automatically reap zombies that devolve to it? (Or to at least have a launchctl option to do so?) – Adrenocorticotropic