<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Assertion in backend causes invalid accesses in driver"
href="https://bugs.llvm.org/show_bug.cgi?id=45164">45164</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Assertion in backend causes invalid accesses in driver
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>10.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Driver
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>daltenty@ibm.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=23218" name="attach_23218" title="Run with address sanitizer enabled on ppc64le">attachment 23218</a> <a href="attachment.cgi?id=23218&action=edit" title="Run with address sanitizer enabled on ppc64le">[details]</a></span>
Run with address sanitizer enabled on ppc64le
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 <a href="https://reviews.llvm.org/D69825">https://reviews.llvm.org/D69825</a> 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>