[LLVMdev] JIT crash takes down host-application
fk.fuchs at googlemail.com
Mon Jul 19 04:46:19 PDT 2010
On a related note is there anything one can do to make the JIT exit
(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.
> 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
>> 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
>> 2010/7/18 Nick Lewycky <nicholas at mxc.ca>
>>> Frank Fuchs wrote:
>>>> I'm doing some tests concerning the embedding of LLVM and clan in my
>>>> 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?
>>> 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:
>>> 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.
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev