diff options
author | Michael Gottesman <mgottesman@apple.com> | 2013-04-18 05:39:45 +0000 |
---|---|---|
committer | Michael Gottesman <mgottesman@apple.com> | 2013-04-18 05:39:45 +0000 |
commit | 323964ca9e8f1f930140fd2ce85bfb17dcdf4e59 (patch) | |
tree | 5cfb7168bda2a27289401bbc0696ff6cd4f28a7d /lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h | |
parent | 9e5181393a192a23d8ebe33a2a4b0e412932ffe0 (diff) | |
download | llvm-323964ca9e8f1f930140fd2ce85bfb17dcdf4e59.zip llvm-323964ca9e8f1f930140fd2ce85bfb17dcdf4e59.tar.gz llvm-323964ca9e8f1f930140fd2ce85bfb17dcdf4e59.tar.bz2 |
[objc-arc] Do not mismatch up retains inside a for loop with releases outside said for loop in the presense of differing provenance caused by escaping blocks.
This occurs due to an alloca representing a separate ownership from the
original pointer. Thus consider the following pseudo-IR:
objc_retain(%a)
for (...) {
objc_retain(%a)
%block <- %a
F(%block)
objc_release(%block)
}
objc_release(%a)
From the perspective of the optimizer, the %block is a separate
provenance from the original %a. Thus the optimizer pairs up the inner
retain for %a and the outer release from %a, resulting in segfaults.
This is fixed by noting that the signature of a mismatch of
retain/releases inside the for loop is a Use/CanRelease top down with an
None bottom up (since bottom up the Retain-CanRelease-Use-Release
sequence is completed by the inner objc_retain, but top down due to the
differing provenance from the objc_release said sequence is not
completed). In said case in CheckForCFGHazards, we now clear the state
of %a implying that no pairing will occur.
Additionally a test case is included.
rdar://12969722
llvm-svn: 179747
Diffstat (limited to 'lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h')
0 files changed, 0 insertions, 0 deletions