<div dir="ltr"><div dir="ltr">Hi Dibyendu,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I am a bit confused about this. I assumed that cantFail() will abort<br>the process on error - but my process doesn't abort.<br>I have cantFail() in a few places, I am not sure if you are suggesting<br>adding the error logging everywhere ...</blockquote></div><div><br></div><div>Are you building LLVM in +Asserts mode? I believe that cantFail should abort in +Asserts builds, but it's effectively a no-op if asserts are disabled.</div><div><br></div><div>If you are building in +Asserts mode it could also be consumeError: that function is intended to silently consume errors.</div><div><br></div><div>Both cantFail and consumeError should be used very carefully. The cantFail function should only be used if you are 100% certain that an error can never occur at runtime if program invariants hold. E.g. adding a symbol to a newly created JITDylib can't fail because there are no existing definitions to clash with. The consumeError function should only be used if you have genuinely dealt with whatever error condition arose. If you think that an error is being silently dropped please see if you can trace it by putting a breakpoint on the ErrorInfoBase constructor and destructor, then following any errors generated up the stack to the point where they're dropped. Silently dropped errors (in +Asserts mode) are likely bugs in the llvm::Error system and we definitely want to get them fixed.</div><div><br></div><div>Regards,</div><div>Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 1:46 PM Dibyendu Majumdar <<a href="mailto:mobile@majumdar.org.uk">mobile@majumdar.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Lang,<br>
<br>
On Mon, 13 Apr 2020 at 21:26, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
><br>
>> I had a look - to be honest I am not sure where the error is being<br>
>> reported from. It looks like this:<br>
>> JIT session error: Symbols not found: [ luaV_tointeger_, luaG_runerror ]<br>
>> I don't think it is from any logging I am doing.<br>
><br>
><br>
> Errors in ORC may trigger cascading failures. E.g. if two different modules M1 and M2 both reference a function "foo" which cannot be resolved, then you have three errors: A failure to resolve "foo", A failure to materialize the symbols in M1, and a failure to materialize the symbols in M2. When such a cascade occurs ORC will usually report the original error(s) via ExecutionSession::reportError (which logs them to stderr by default) and return a derived error (e.g. failure-to-materialize) to callers. I believe you're seeing the logged error, and you will see a failure-to-materialize error if you log the result that reaches cantFail in your example above.<br>
><br>
<br>
I am a bit confused about this. I assumed that cantFail() will abort<br>
the process on error - but my process doesn't abort.<br>
I have cantFail() in a few places, I am not sure if you are suggesting<br>
adding the error logging everywhere ...<br>
<br>
Thanks and Regards<br>
Dibyendu<br>
</blockquote></div>