[LLVMdev] JIT crash takes down host-application

Garrison Venn gvenn.cfe.dev at gmail.com
Mon Jul 19 03:15:49 PDT 2010


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/440bae8f/attachment.html>


More information about the llvm-dev mailing list