[PATCH] D74300: [ORC] Add generic initializer/deinitializer support.
Alex Zinenko via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 20 13:16:49 PST 2020
ftynse added a comment.
In D74300#1885092 <https://reviews.llvm.org/D74300#1885092>, @rriddle wrote:
> In D74300#1885049 <https://reviews.llvm.org/D74300#1885049>, @lhames wrote:
>
> > Oops -- The ThinLtoJIT example should be fixed by 6de21c556d1 <https://reviews.llvm.org/rG6de21c556d159d29e7957821fa8b83ef68083b76>, rather.
> >
> > @ftynse I'll be on discord if you want to chat about this in real time. Side note: I noticed you're getting an assertion after the error:
>
>
> I just pinged on discord :)
Thanks for picking this up! :) I'm in a different time zone so it may be tricky for me to be more reactive.
>> /var/lib/buildkite-agent/builds/buildkite-6d6d45d7dd-4njcg-1/mlir/mlir-core/llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h:149: llvm::orc::SymbolStringPool::~SymbolStringPool(): Assertion `Pool.empty() && "Dangling references at pool destruction time"' failed.
>>
>> That indicates that you're holding SymbolStringPtrs allocated by LLJIT after the JIT is torn down, but I can't see where they'd be held. If you can arrange for the LLJIT instance to outlive these strings it will eliminate this assertion.
>
> Yeah, the string pool errors are orthogonal, but very unfortunate. Those really need to be fixed.
Indeed, I remember seeing this quite a while ago, but it only manifests in the situations where the executor is going to abort anyway, so we did not spend too much time trying to fix it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D74300/new/
https://reviews.llvm.org/D74300
More information about the llvm-commits
mailing list