[PATCH] D24781: [ubsan] Respect log_to_syslog=1 on Darwin

[Vedant Kumar via llvm-commits]

vsk added a comment.

In https://reviews.llvm.org/D24781#548200, @zaks.anna wrote:

> > Or, should I just introduce Mac-specific logic to remove color codes in the PrintToLog function introduced by this patch?
>
>
> 1. Do you want to log UBSan errors into CrashLog? If so, how will you accomplish that?


No, I don't have plans to do this. The typical workflow with ubsan is to continue after an error/warning is reported. In trap or abort mode, it's easier to run the instrumented program with a debugger than to rely on crashlog.

> 2. I've tried adding the logging into every Printf, but it does not work for ASan and TSan, see the following comment in r253688. This may or may not apply to UBSan. Another smaller concern is that using different logging strategies is not consistent. " I've initially tried to log to syslog during printing, which is done on Android right now. The advantage is that if we crash during error reporting or the produced error does not go through ScopedInErrorReport, we would still get a (partial) message in the syslog. However, that solution is very problematic on OS X. One issue is that the logging routine uses GCD, which may spawn a new thread on its behalf. In many cases, the reporting logic locks threadRegistry, which leads to deadlocks. "


I don't think the same issue affects ubsan because it doesn't have a thread registry lock. Asan (and presumably also tsan) grabs a thread registry lock when preparing error reports. So as long as `asl_log` does not launch another copy of the instrumented process and triggers more UB by jumping into its `main()`, we will avoid double-locking scenarios with ubsan.

> > Should I modify LogMessageOnPrintf on Mac platforms so that it prints to syslog when common_flags()->abort_on_error isn't set?

> 

> 

> This might not work because of the problem described above.

> 

> What we do instead is record all the info into a buffer that will be used for CrashReporting and log that to syslog before the process ends.


I see your point that having different logging strategies is strange, but I think there are advantages to logging errors to syslog directly instead of doing it at exit. For one, we're not limited by the fixed-size crashlog buffer. Secondly, we can extract errors from long-running apps or daemons without having to shut them down. In some situations (e.g Xcode UI Tests), instrumented apps are killed with SIGTERM and their atexit() handlers never run..


https://reviews.llvm.org/D24781