[llvm] 3d931e8 - [ORC] Don't take ownership of the trampoline pool in LazyReexportsManager.
Lang Hames via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 21 10:39:09 PDT 2020
Hey Dave,
Richard and I chatted about this on discord. The eventual fix was
https://github.com/llvm/llvm-project/commit/71292379d757f7a40b1771ade7738e25d7ddece5
, which makes LazyCallThroughManager's destructor virtual.
Regards,
Lang.
On Mon, Jul 20, 2020 at 3:31 PM David Blaikie <dblaikie at gmail.com> wrote:
> ping for Lang/subscribing to this thread for discussion
>
> On Tue, Jul 14, 2020 at 5:35 PM Richard Smith via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> >
> > On Tue, 14 Jul 2020 at 11:00, Lang Hames via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >>
> >>
> >> Author: Lang Hames
> >> Date: 2020-07-14T10:56:45-07:00
> >> New Revision: 3d931e85f1ca8bf72d3bfcd34390cb5ec0d73aa5
> >>
> >> URL:
> https://github.com/llvm/llvm-project/commit/3d931e85f1ca8bf72d3bfcd34390cb5ec0d73aa5
> >> DIFF:
> https://github.com/llvm/llvm-project/commit/3d931e85f1ca8bf72d3bfcd34390cb5ec0d73aa5.diff
> >>
> >> LOG: [ORC] Don't take ownership of the trampoline pool in
> LazyReexportsManager.
> >>
> >> LazyReexportsManager instances use the trampoline pool, but they don't
> need to
> >> own it. Keeping TrampolinePool ownership separate allows re-use of the
> >> trampoline pool by other clients.
> >>
> >> Added:
> >>
> >>
> >> Modified:
> >> llvm/include/llvm/ExecutionEngine/Orc/LazyReexports.h
> >> llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp
> >>
> >> Removed:
> >>
> >>
> >>
> >>
> ################################################################################
> >> diff --git a/llvm/include/llvm/ExecutionEngine/Orc/LazyReexports.h
> b/llvm/include/llvm/ExecutionEngine/Orc/LazyReexports.h
> >> index 7972ed430048..85c1fe7b19a9 100644
> >> --- a/llvm/include/llvm/ExecutionEngine/Orc/LazyReexports.h
> >> +++ b/llvm/include/llvm/ExecutionEngine/Orc/LazyReexports.h
> >> @@ -55,8 +55,7 @@ class LazyCallThroughManager {
> >> TrampolinePool::NotifyLandingResolvedFunction;
> >>
> >> LazyCallThroughManager(ExecutionSession &ES,
> >> - JITTargetAddress ErrorHandlerAddr,
> >> - std::unique_ptr<TrampolinePool> TP);
> >> + JITTargetAddress ErrorHandlerAddr,
> TrampolinePool *TP);
> >>
> >> struct ReexportsEntry {
> >> JITDylib *SourceJD;
> >> @@ -67,9 +66,7 @@ class LazyCallThroughManager {
> >> Expected<ReexportsEntry> findReexport(JITTargetAddress
> TrampolineAddr);
> >> Error notifyResolved(JITTargetAddress TrampolineAddr,
> >> JITTargetAddress ResolvedAddr);
> >> - void setTrampolinePool(std::unique_ptr<TrampolinePool> TP) {
> >> - this->TP = std::move(TP);
> >> - }
> >> + void setTrampolinePool(TrampolinePool &TP) { this->TP = &TP; }
> >>
> >> private:
> >> using ReexportsMap = std::map<JITTargetAddress, ReexportsEntry>;
> >> @@ -79,7 +76,7 @@ class LazyCallThroughManager {
> >> std::mutex LCTMMutex;
> >> ExecutionSession &ES;
> >> JITTargetAddress ErrorHandlerAddr;
> >> - std::unique_ptr<TrampolinePool> TP;
> >> + TrampolinePool *TP = nullptr;
> >> ReexportsMap Reexports;
> >> NotifiersMap Notifiers;
> >> };
> >> @@ -105,10 +102,13 @@ class LocalLazyCallThroughManager : public
> LazyCallThroughManager {
> >> if (!TP)
> >> return TP.takeError();
> >>
> >> - setTrampolinePool(std::move(*TP));
> >> + this->TP = std::move(*TP);
> >> + setTrampolinePool(*this->TP);
> >> return Error::success();
> >> }
> >>
> >> + std::unique_ptr<TrampolinePool> TP;
> >
> >
> > This code has had undefined behavior for a while by creating
> LocalLazyCallThroughManagers and then deleting them via
> unique_ptr<LazyCallThroughManager>, but after this commit it started
> leaking (by not calling the derived class destructor and thereby not
> deleting the TrampolinePool) and potentially crashing (by passing the wrong
> size to sized operator delete, due to LocalLazyCallThroughMananger now
> being larger than LazyCallThroughManager). This started crashing for us
> because our sized delete happens to check that the passed size is correct
> in debug builds.
> >
> > I've fixed the immediate problems in llvmorg-11-init-20842-g099fd374847
> by changing the unique_ptr<LazyCallThroughManager>s to
> unique_ptr<LocalLazyCallThroughManager>s, but I'm not sure if that was your
> intent or whether the base class should instead have a virtual destructor.
> Could you take a look and double-check? Thanks!
> >
> >>
> >> +
> >> public:
> >> /// Create a LocalLazyCallThroughManager using the given ABI. See
> >> /// createLocalLazyCallThroughManager.
> >>
> >> diff --git a/llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp
> b/llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp
> >> index ff66955082d8..153f6b80784f 100644
> >> --- a/llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp
> >> +++ b/llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp
> >> @@ -17,13 +17,14 @@ namespace llvm {
> >> namespace orc {
> >>
> >> LazyCallThroughManager::LazyCallThroughManager(
> >> - ExecutionSession &ES, JITTargetAddress ErrorHandlerAddr,
> >> - std::unique_ptr<TrampolinePool> TP)
> >> - : ES(ES), ErrorHandlerAddr(ErrorHandlerAddr), TP(std::move(TP)) {}
> >> + ExecutionSession &ES, JITTargetAddress ErrorHandlerAddr,
> TrampolinePool *TP)
> >> + : ES(ES), ErrorHandlerAddr(ErrorHandlerAddr), TP(TP) {}
> >>
> >> Expected<JITTargetAddress>
> LazyCallThroughManager::getCallThroughTrampoline(
> >> JITDylib &SourceJD, SymbolStringPtr SymbolName,
> >> NotifyResolvedFunction NotifyResolved) {
> >> + assert(TP && "TrampolinePool not set");
> >> +
> >> std::lock_guard<std::mutex> Lock(LCTMMutex);
> >> auto Trampoline = TP->getTrampoline();
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200721/168c5a19/attachment.html>
More information about the llvm-commits
mailing list