Assertion in backend causes invalid accesses in driver #44509
Description
| Bugzilla Link | 45164 |
| Resolution | FIXED |
| Resolved on | Mar 13, 2020 12:46 |
| Version | 10.0 |
| OS | Linux |
| Blocks | #43900 |
| Attachments | Run with address sanitizer enabled on ppc64le, Run with address sanitizer enabled on ppc64le (full output) |
| CC | @zmodem,@hubert-reinterpretcast,@zygoloid,@rgal |
Extended Description
When running clang 10.0.0-rc3 with the clang/test/CodeGenObjC/illegal-UTF8.m testcase, we get an (expected) assertion from the backend, but during the driver shutdown and cleanup after that assertion we get an invalid access related to Timers that were original created by CC1. Depending on the platform and what exactly happens to be there at the invalid address we may get a crash or hang due to an infinite loop in the Timer cleanup (which happens on AIX).
Originally found on AIX, but I've reproduced here on RHEL 7 ppc64le with address sanitizers to highlight the problematic access.
--
It looks like this is present since https://reviews.llvm.org/D69825 changes the default behaviour of the driver to run cc1 in process.
Instead of spawning, the driver now uses CrashRecoveryContext to wrap its execution. The in process call to CC1 creates a few timer objects on the stack and adds them to the linked list in the DefaultTimerGroup. But when the backend asserts the error handling code in CrashRecovery context longjmps back to the driver and after longjmp unwinds the stack, the pointers in the ManagedStatic refer to invalid locations in discarded stack frames (which may be overwritten by subsequent frames). When llvm::shutdown is called by the driver as it terminates it runs a cleanup on the ManagedStatic DefaultTimerGroup and reads the invalid stack region.