[LLVMdev] JIT crash takes down host-application

[Frank Fuchs]

On a related note is there anything one can do to make the JIT exit
gracefully?
(except feeding it with IR which doesn't crash it).

2010/7/19 Frank Fuchs <fk.fuchs at googlemail.com>

> Is there a way to intercept the calls to abort() or exit(), specifically ?
> Disabling all external symbol resolution seems not really feasable since I
> need some std libs.
>
> -Frank
>
> 2010/7/19 Garrison Venn <gvenn.cfe.dev at gmail.com>
>
> You could use shared memory or the equivalent of UNIX domain sockets. On a
>> UNIX system, you will also probably want to catch
>> SIGCHLD along with implementing "nowait" handling behavior in the parent.
>> This is of course a low level approach. Higher level
>> libraries that you may be using, or other OSs may provide their own
>> wrappers.
>>
>> Garrison
>>
>> On Jul 19, 2010, at 4:05, Frank Fuchs wrote:
>>
>> Ok, thank you for your explanation. Is it possible for forked processes to
>> share data? Especially for the child process to send some data to the
>> parent?
>>
>> -Frank
>>
>> 2010/7/18 Nick Lewycky <nicholas at mxc.ca>
>>
>>> Frank Fuchs wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm doing some tests concerning the embedding of LLVM and clan in my
>>>> application.
>>>> Now I stumbled across the following ... which disturbs me. If the jitted
>>>> program crashes,
>>>> like e.g. if it contains an assert(0==1) or calls an external function
>>>> which cannot be resolved,
>>>> the hosting app goes down as well. There seems no error catch.
>>>>
>>>> Can this anyhow be circumvented?
>>>>
>>>
>>> Fork?
>>>
>>> LLVM JIT is not a secure VM like Java. Programs running under the JIT are
>>> free to make any memory operation or function call that the enclosing
>>> program could, even _exit(). You can try to restrict function calls by
>>> removing the name resolution:
>>>
>>>
>>>
>>> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460
>>>
>>> and/or installing your own (see InstallLazyFunctionCreator), but
>>> ultimately they're the same process/task from the point of view of the
>>> operating system and there's no "llvm security model" or anything like that.
>>>
>>> If you're very determined, you could create an LLVM IR transformation
>>> pass which checks every load/store/call and verifies that it's safe, and if
>>> it's not verifiable at compile time makes it call back into your program at
>>> runtime to do the check and proceed only if it is.
>>>
>>> Or if you don't need it to be in the same process, don't put it there and
>>> let the OS handle the rest.
>>>
>>> Nick
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/8eb776f9/attachment.html>