aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2014-04-29 21:52:46 +0000
committerDavid Blaikie <dblaikie@gmail.com>2014-04-29 21:52:46 +0000
commit7a1e775a7e6c3c7c7c283253dd8be39ff7c6da92 (patch)
treeada65930ad565a7029ec1c254e418b8f5c9d21ac /clang/lib/Frontend/CompilerInvocation.cpp
parent836b1aed05c5d909fb399e8de9a299f4c5bed1d6 (diff)
downloadllvm-7a1e775a7e6c3c7c7c283253dd8be39ff7c6da92.zip
llvm-7a1e775a7e6c3c7c7c283253dd8be39ff7c6da92.tar.gz
llvm-7a1e775a7e6c3c7c7c283253dd8be39ff7c6da92.tar.bz2
PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFile
This starts in MCJIT::getSymbolAddress where the unique_ptr<object::Binary> is release()d and (after a cast) passed to a single caller, MCJIT::addObjectFile. addObjectFile calls RuntimeDyld::loadObject. RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile And the pointer is never owned at this point. I say this point, because the alternative codepath, RuntimeDyldMachO::createObjectFile certainly does take ownership, so this seemed like a good hint that this was a/the right place to take ownership. llvm-svn: 207580
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions