Why do sanitizers abort on error by default on mac and android?

[cjappl]

Hi,

What is the history of aborting on error on mac and android in a sanitizer? What advantage does it bring versus just exiting non-zero? Why just on these platforms and not all platforms?

(for my own education)

More background:
It seems like the sanitizers die with SIGABT instead of exiting non-zero, but this is platform specific (and may be overridden by the user). From sanitizer_flags.inc:

llvm/llvm-project/blob/fe946bfb728481a249282fb1e14378bf444defd3/compiler-rt/lib/sanitizer_common/sanitizer_flags.inc#L250-L253

Why is the behavior different on android and apple? Did this bring some sort of advantage?

It seems like the feature originally existed in ASAN, and was introduced here:

[asan] Set abort_on_error=1 by default on OS X

But the commit doesn’t describe why this decision was made.

[cjappl]

Pinging @kubamracek , as it looks like you introduced this change way back in 2015. Thanks for any knowledge you can share

[kubamracek]

A crash of a process (e.g. through abort() or by segfault-ing) on macOS generates an incredibly useful crashlog file with thread backtraces, and lots more details. Ending the process with exit() doesn’t do that.

[cjappl]

Aha!

Thank you for the response, perhaps that is one of the things that contributes to my question from yesterday:

Symbolizer MacOS <unknown module>

I’m wondering if someone could explain a little bit about how the sanitizer symbolizer works on mac, and how it differs from linux. Specifically, when I run, I see stack traces with a lot of < unknown module > which could impair a users ability to diagnose the problem we are reporting. I am trying to implement better symbolized stacks for RTSan, and currently there is a large disparity between linux: $ RTSAN_SYMBOLIZER_PATH=(which llvm-symbolizer-10) RTSAN_OPTIONS="halt_on_error=false" ./buil…

I’ll have to poke around and see if this new info about abort improves anything.

[hctim]

Android is similar to iOS, in that if we call abort() then debuggerd will create a tombstone on disk. The backtraces/register contents are garbage in the tombstone (because it’s from where abort() was called in the sanitizer runtime), but it has logcat and memory mappings and such.

Also, tombstones get special handling on Android as they’re a crash. For example, you can see the crashes for an app using the ApplicationExitInfo API. This is not the case for exit().

[cjappl]

Just a thought:

Would it be worthwhile to document this in either sanitizer_flags.inc, or in the external documentation?

I have been a user of the sanitizers for a good number of years, but didn’t ever considering checking my mac crash logs for better info on the problems. It may be nice to advertise this to the user.

I’m happy to follow up with a PR if we think this is a good idea. Any thoughts on where it might live? I don’t see an obvious .rst that corresponds to ‘common sanitizer behavior’.

Minimally, I could put a one liner comment in sanitizer_flags.inc describing why it’s done internally. That could help other devs, but is less helpful to the public at large.