llvm dev - Aug 2019 - VModuleKey K not valid here

Hi,

I am getting following assertion failure when attempting to remove a module.

/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error
llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT,
IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with
BaseLayerT =
llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer,
llvm::orc::SimpleCompiler>,
std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)>
>; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager;
IndirectStubsMgrT = llvm::orc::IndirectStubsManager;
llvm::orc::VModuleKey = long unsigned int]: Assertion `I !LogicalDylibs.end()
&& "VModuleKey K not valid here"' failed.

1) Can 0 ever be a valid VModuleKey? How can one reliably detect an
invalid VModuleKey?
2) Secondly it seems to me that  following the assertion there should
be a check so that the code dosn't continue? It is causing
segmentation fault in release builds.

Regards
Dibyendu

Hi Dibyendu,

1) Can 0 ever be a valid VModuleKey? How can one reliably detect an
invalid
> VModuleKey?

I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the
the VModuleKey is present in the LogicalDylibs map. That means that you
have to have used that key in an addModule call, e.g.:

CODLayer.addModule(K, std::move(M));

and not subsequently removed the key with a call to removeModule.

2) Secondly it seems to me that  following the assertion there should be a
check so that the code dosn't continue? It is causing segmentation fault in
release builds.

There should not be any check other than the assertion. Assertions aren't
for recoverable errors or logging, they're only for verifying that code is
being used according to contract. In this case the contract is that
removeModule is only called with valid keys. If the assertion is triggering
then either the key you're using is invalid, or my implementation of
CompileOnDemandLayer (or the assert itself) is invalid. We just need to fix
the offending code.

Out of interest: What are your plans for removeModule? It's currently
unimplemented in ORCv2. Understanding people's use cases will help with
design and prioritization.

Cheers,
Lang.

On Tue, Aug 13, 2019 at 1:50 PM Dibyendu Majumdar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I am getting following assertion failure when attempting to remove a
> module.
>
> /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error
> llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT,
> IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with
> BaseLayerT >
llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer,
> llvm::orc::SimpleCompiler>,
>
std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)>
> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager;
> IndirectStubsMgrT = llvm::orc::IndirectStubsManager;
> llvm::orc::VModuleKey = long unsigned int]: Assertion `I !>
LogicalDylibs.end() && "VModuleKey K not valid here"'
failed.
>
> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an
> invalid VModuleKey?
> 2) Secondly it seems to me that  following the assertion there should
> be a check so that the code dosn't continue? It is causing
> segmentation fault in release builds.
>
> Regards
> Dibyendu
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190813/93c7a506/attachment.html>

Hi Lang,

On Tue, 13 Aug 2019 at 22:15, Lang Hames <lhames at gmail.com>
wrote:
>
>> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an
invalid VModuleKey?
>
>
> I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the
the VModuleKey is present in the LogicalDylibs map. That means that you have to
have used that key in an addModule call, e.g.:
>
> CODLayer.addModule(K, std::move(M));
>
> and not subsequently removed the key with a call to removeModule.
Yes indeed that is what happened. So to prevent that I need to check
if VModuleKey was ever initialized ... how do I do that? I would have
to have to add another flag to track the initialized state.
The reason for it not being initialized is that sometimes I cannot
generate JIT code because some bytecode is not yet supported.
>
> 2) Secondly it seems to me that  following the assertion there should be a
check so that the code dosn't continue? It is causing segmentation fault in
release builds.
>
> There should not be any check other than the assertion. Assertions
aren't for recoverable errors or logging, they're only for verifying
that code is being used according to contract. In this case the contract is that
removeModule is only called with valid keys. If the assertion is triggering then
either the key you're using is invalid, or my implementation of
CompileOnDemandLayer (or the assert itself) is invalid. We just need to fix the
offending code.
>
Sure - in that case there ought be some value of VModuleKey that is
invalid. Example NULL for pointers. Otherwise users have to track
separately whether it is initialized or not.
Having said that just as free(NULL) doesn't do anything, and
fclose(NULL) doesn't either, it seems better to not continue to try to
access 'I' if it doesn't exist. Or the assertion should trigger even
in release builds.
> Out of interest: What are your plans for removeModule? It's currently
unimplemented in ORCv2. Understanding people's use cases will help with
design and prioritization.
>
Ideally it should be possible to delete modules after the code is compiled.
And also delete compiled functions if they are no longer needed.
In my case, the language is Lua based, functions are garbage
collected. So any associated stuff should be deleted when the function
is collected. Sometimes each function is in its own module, but
sometimes several functions are in one module. Either way when the
last function in a module is deleted, I invoke removeModule().

I think in ORCv2 stuff never gets deleted?

Regards
Dibyendu
> On Tue, Aug 13, 2019 at 1:50 PM Dibyendu Majumdar via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I am getting following assertion failure when attempting to remove a
module.
>>
>> /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error
>> llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT,
CompileCallbackMgrT,
>> IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with
>> BaseLayerT =
llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer,
>> llvm::orc::SimpleCompiler>,
>>
std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)>
>> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager;
>> IndirectStubsMgrT = llvm::orc::IndirectStubsManager;
>> llvm::orc::VModuleKey = long unsigned int]: Assertion `I !>>
LogicalDylibs.end() && "VModuleKey K not valid here"'
failed.
>>
>> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an
>> invalid VModuleKey?
>> 2) Secondly it seems to me that  following the assertion there should
>> be a check so that the code dosn't continue? It is causing
>> segmentation fault in release builds.
>>
>> Regards
>> Dibyendu
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev