aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h
diff options
context:
space:
mode:
authorMichael Gottesman <mgottesman@apple.com>2013-04-18 05:39:45 +0000
committerMichael Gottesman <mgottesman@apple.com>2013-04-18 05:39:45 +0000
commit323964ca9e8f1f930140fd2ce85bfb17dcdf4e59 (patch)
tree5cfb7168bda2a27289401bbc0696ff6cd4f28a7d /lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h
parent9e5181393a192a23d8ebe33a2a4b0e412932ffe0 (diff)
downloadllvm-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