Error when testing on iOS simulator: Couldn't register with the bootstrap server

lostInTransit picture lostInTransit · Apr 25, 2009 · Viewed 127.5k times · Source

I was testing my app on the simulator when it crashed on clicking a button of a UIAlertView. I stopped debugging there, made some changes to the code and built the app again. Now when I run the application, I get this error in the console

Couldn't register com.myApp.debug with the bootstrap server. Error: unknown error code. This generally means that another instance of this process was already running or is hung in the debugger.Program received signal: “SIGABRT”.

I tried removing the app from the simulator, doing a clean build but I still get this error when I try to run the app.

What should I do to be able to run the app on my simulator again?

Answer

smparkes picture smparkes · Oct 22, 2011

status: this has been seen as recently as Mac OS 10.8 and Xcode 4.4.

tl;dr: This can occur in two contexts: when running on the device and when running on the simulator. When running on the device, disconnecting and reconnecting the device seems to fix things.

Mike Ash suggested

launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove

This doesn't work all the time. In fact, it's never worked for me but it clearly works in some cases. Just don't know which cases. So it's worth trying.

Otherwise, the only known way to fix this is to restart the user launchd. Rebooting will do that but there is a less drastic/faster way. You'll need to create another admin user, but you only have to do that once. When things wedge, log out as yourself, log in as that user, and kill the launchd that belongs to your main user, e.g.,

sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`

substituting your main user name for user_id. Logging in again as your normal user gets you back to a sane state. Kinda painful, but less so than a full reboot.

details:

This has started happening more often with Lion/Xcode 4.2. (Personally, I never saw it before that combination.)

The bug seems to be in launchd, which inherits the app process as a child when the debugger stops debugging it without killing it. This is usually signaled by the app becoming a zombie, having a process status of Z in ps.

The core issue appears to be in the bootstrap name server which is implemented in launchd. This (to the extent I understand it) maps app ids to mach ports. When the bug is triggered, the app dies but doesn't get cleaned out of the bootstrap server's name server map and as result, the bootstrap server refuses to allow another instance of the app to be registered under the same name.

It was hoped (see the comments) that forcing launchd to wait() for the zombie would fix things but it doesn't. It's not the zombie status that's the core problem (which is why some zombies are benign) but the bootstrap name server and there's no known way to clear this short of killing launchd.

It looks like the bug is triggered by something bad between Xcode, gdb, and the user launchd. I just repeated the wedge by running an app in the iphone simulator, having it stopped within gdb, and then doing a build and run to the ipad simulator. It seems to be sensitive to switching simulators (iOS 4.3/iOS 5, iPad/iPhone). It doesn't happen all the time but fairly frequently when I'm switching simulators a lot.

Killing launchd while you're logged in will screw up your session. Logging out and logging back in doesn't kill the user launchd; OS X keeps the existing process around. A reboot will fix things, but that's painful. The instructions above are faster.

I've submitted a bug to Apple, FWIW. rdar://10330930