Debugging launchd
wuntee.sexy (via Hacker News):
The reason I had an interest in debugging
launchdis because I had been able to trigger some crashes.launchdis likeinitfor linux; the kernel spawns it as PID 1 and every process is executed under it. Whenlaunchdcrashes, 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
launchdcrashes, there should be a crashdump file like any other process, however from thelaunchdre-write, I can only assume Apple had disabled that feature. In turn, you get a semi-useful/usr/bin/sampleoutput 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
launchdupon it crashing, redirecting the output to a file (this can be done as a one-liner) […] And voila! I now had a specific location, withinlaunchd, of where this crash is occurring. That being said, it was still quite hard backtracing to understand exactly why the crash occurred.
