Sunday, May 17, 2015 [Tweets] [Favorites]

Debugging launchd

wuntee.sexy (via Hacker News):

The reason I had an interest in debugging launchd is because I had been able to trigger some crashes. launchd is like init for linux; the kernel spawns it as PID 1 and every process is executed under it. When launchd crashes, the kernel panics, and your machine reboots with the “there was a problem, press any key to continue” screen. User-land triggering kernel bugs is obviously interested due to the trust boundary crossed.

[…]

From everything I had read about other launchd crashes, there should be a crashdump file like any other process, however from the launchd re-write, I can only assume Apple had disabled that feature. In turn, you get a semi-useful /usr/bin/sample output located in the /var/log/com.apple.xpc.launchd/ directory. Although this gives a bit more information than the kernel panic, I still am leaps and bounds away from finding the root cause of these crashes.

[…]

My next thought was to move to kernel debugging, and try and catch the crash before it jumped into the kernel. […] When dealing with kernel crashes, having to reboot and re-attach every time became quite annoying, so I found myself using the flags that waited for the debugger upon panic.

[…]

I ran a simple dtrace script to perform a stacktrace on launchd upon it crashing, redirecting the output to a file (this can be done as a one-liner) […] And voila! I now had a specific location, within launchd, of where this crash is occurring. That being said, it was still quite hard backtracing to understand exactly why the crash occurred.

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment