Debugging Endpoint Security Client daemon

maybe increase the timeout

You will not be able to debug an ES client interactively. Raising the timeout won’t help because the system is effectively deadlocked by your attempt to attach, and a longer timeout just means that it’ll stay deadlocked for longer.

Some of our debugging tools support a -forkCorpse option that allows them to work against an ES client. See this post for more. AFAIK this is not true for LLDB.

How you proceed here kinda depends on your goals:

• If you want to debug interactively, using LLDB to step through your ES client code, that’s simply not feasible.

• If you want to examine the state of your ES client after a problem has cropped up, you have a number of options in that space. Let me know if you’d like to pursue those.

I generally avoid trying to interactively debug this sort of code in place. Rather:

• I add logging to track the interactions between my code and the OS.

• If I need to interactively debug my code, I put it into a test harness (built using the understanding that I gained from my logging) and debug that.

This is the same approach I used to use for debugging KEXTs, and for the same reason: Interactive debugging of low-level system components is, at best, deeply unpleasant and, in the worst case, completely infeasible.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

This is the same approach I used to use for debugging KEXTs, and for the same reason: Interactive debugging of low-level system components is, at best, deeply unpleasant and, in the worst case, completely infeasible.

Deeply unpleasant. Quinn, you are a master of understatement :)