[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