dyld iteration in signal handlers

What are my options if I want to iterate over loaded images (dynamic libraries) within a signal handler? I have a few solutions that might work, but without going too much into them, i'm curious if anyone has experience here, or ideas what to look into.

Cheers, AC

Answered by DTS Engineer in 849431022
What are my options if I want to iterate over loaded images … within a signal handler?

There are no valid options for this. None of the dynamic linker APIs you need are async signal safe [1]. For more background, see Implementing Your Own Crash Reporter.

However, you might be able to make some progress by doing this work outside of signal handler and stashing it in a global. If you search the above-mentioned post for atomic and offline, you’ll find my advice for that.

Having said that, I must reiterate a key point from that post: If you’re building your own crash reporter, please don’t. There’s no way to do that in a way that’s simultaneously reliable, binary compatible, and sufficient to debug complex problems.

Share and Enjoy

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

[1] And this is not just a theoretical concern. I’ve seen many watchdog crash reports caused by third-party crash reporters that deadlock because they tried to call dynamic linker APIs from a signal handler. The dynamic linker protects its state with a mutex, so if your async signal handler runs while some other thread is doing stuff in the dynamic linker, you deadlock. Eventually the watchdog kicks in and kills your process. That generates an Apple crash report, and the Apple crash report clearly shows the problem with the third-party crash reporter, but it has useful info about the original crash. This is a classic example of a third-party crash reporter doing more harm than good. See the Preserve the Apple Crash Report section of Implementing Your Own Crash Reporter for more on that.

What are my options if I want to iterate over loaded images … within a signal handler?

There are no valid options for this. None of the dynamic linker APIs you need are async signal safe [1]. For more background, see Implementing Your Own Crash Reporter.

However, you might be able to make some progress by doing this work outside of signal handler and stashing it in a global. If you search the above-mentioned post for atomic and offline, you’ll find my advice for that.

Having said that, I must reiterate a key point from that post: If you’re building your own crash reporter, please don’t. There’s no way to do that in a way that’s simultaneously reliable, binary compatible, and sufficient to debug complex problems.

Share and Enjoy

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

[1] And this is not just a theoretical concern. I’ve seen many watchdog crash reports caused by third-party crash reporters that deadlock because they tried to call dynamic linker APIs from a signal handler. The dynamic linker protects its state with a mutex, so if your async signal handler runs while some other thread is doing stuff in the dynamic linker, you deadlock. Eventually the watchdog kicks in and kills your process. That generates an Apple crash report, and the Apple crash report clearly shows the problem with the third-party crash reporter, but it has useful info about the original crash. This is a classic example of a third-party crash reporter doing more harm than good. See the Preserve the Apple Crash Report section of Implementing Your Own Crash Reporter for more on that.

Thanks for the response.

I've read your post many times over, it's the reference, and it's a great one. That being said, obviously your stance is the right one, but as you sort of mention, some of us don't have a choice of writing a crash reporter because the one supplied to us by the OS is too limited or just doesn't cover everything we need.

That being said, I'm curious what you think about using task_info and TASK_DYLD_INFO, and caching that address. That is not signal safe, but after that we're talking lockless access to a mutable list that will only ever grow which is way better than wasting resources caching dyld updates, and is signal safe.

dyld iteration in signal handlers
 
 
Q