Switch application context in remote kernel debug via lldb?

In OSX, launchd is PID1. In userspace, it is obviously impossible to attach to that process, but if that is the case, how do you debug a crash in launchd? I assume there has to be a way of changing to an application/PID context in lldb, but is it possible via a remote kernel debug session? Anything I have tried via the process command has been unsuccessful.

Some additional context:

In the past, once launchd crashes, there were coredumps in /Library/Logs/DiagnosticReports/. Now, I am seeing launchd crash, which is causing a kernel panic due to the check in xnu-2782.1.97/bsd/kern/kern_exit.c:357 which triggers a kernel panic in the DiagnosticReports directory, however it doesn’t give any context of launchd. I did see that there are /usr/bin/sample output of launchd in /private/var/log/com.apple.xpc.launchd/, however it doesn’t really give much context either. I did notice that there are some dtrace hooks for launchd exit, but before I write a dtrace script (which I also dont know will work):

  • Is it possible to use a lldb when remote kernel debugging to switch contexts to pid1/launchd?

  • If not, is there a way to cause launchd to output a coredump once it crashes?

  • Is there any other way of debugging launchd that I am not thinking about?

Thanks.

In OSX, `launchd` is PID1. In userspace, it is obviously impossible to attach to that process, but if that is the case, how do you debug a crash in `launchd`? I assume there has to be a way of changing to an application/PID context in lldb, but is it possible via a remote kernel debug session? Anything I have tried via the `process` command has been unsuccessful.

Did you try running LLDB as root?

% sudo xcrun lldb
(lldb) process attach -n launchd

Some additional context:

In the past, once launchd crashes, there were coredumps in /Library/Logs/DiagnosticReports/. Now, I am seeing launchd crash, which is causing a kernel panic due to the check in `xnu-2782.1.97/bsd/kern/kern_exit.c:357` which triggers a kernel panic in the DiagnosticReports directory, however it doesn't give any context of launchd. I did see that there are /usr/bin/sample output of launchd in /private/var/log/com.apple.xpc.launchd/, however it doesn't really give much context either. I did notice that there are some dtrace hooks for launchd exit, but before I write a dtrace script (which I also dont know will work):

* Is it possible to use a lldb when remote kernel debugging to switch contexts to pid1/launchd?

I am not sure if this can be done with public KDK files. I know internally there are ways to create a new connection to a user space process that still goes through the kernel python macros. They make a new GDB remote connection purely in python that give you a view into the user space process. It knows when doing memory reads to use the right translation tables etc so you can read memory as if you were in that user space process, but I don't know if that is in public dSYM.

* If not, is there a way to cause launchd to output a coredump once it crashes?

Not sure.

* Is there any other way of debugging launchd that I am not thinking about?

You could run debugserver on launchd and attach from another machine? Not sure if launchd being stopped would prevent you from being able to attach though.