[PATCH] D26809: [lli] Handle SIGSEGV in Jit'ed code more gracefully.

[Filipe Cabecinhas via llvm-commits]

What happens if the process wants to handle SIGSEGV?
You can't say it's in JITted code on the handler, as the signal might come
from other parts of code, no?

Thank you,
Filipe

On Thu, 17 Nov 2016 at 20:22, Davide Italiano via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> davide created this revision.
> davide added reviewers: lhames, Bigcheese, rnk.
> davide added a subscriber: llvm-commits.
>
> Before, this just crashed lli. Now, instead, SIGSEGV is intercepted and an
> error message is emitted.
> *TODO: test on windows (the signal interface seems to be the same, but I
> haven't a machine to try on ATM.
> Fixes https://llvm.org/bugs/show_bug.cgi?id=30650
>
>
> https://reviews.llvm.org/D26809
>
> Files:
>   include/llvm/Support/Process.h
>   lib/Support/Unix/Process.inc
>   lib/Support/Windows/Process.inc
>   tools/lli/lli.cpp
>
>
> Index: tools/lli/lli.cpp
> ===================================================================
> --- tools/lli/lli.cpp
> +++ tools/lli/lli.cpp
> @@ -357,6 +357,14 @@
>    llvm_unreachable("Unrecognized opt level.");
>  }
>
> +void segfaultHandler(int arg0) {
> +  // FIXME: is llvm::errs() signal-safe? If not,
> +  // maybe we should just set a flag and return/exit
> +  // in the main loop.
> +  llvm::errs() << "SIGSEGV in JIT'ed code\n";
> +  exit(1);
> +}
> +
>
>  //===----------------------------------------------------------------------===//
>  // main Driver function
>  //
> @@ -366,6 +374,11 @@
>
>    atexit(llvm_shutdown); // Call llvm_shutdown() on exit.
>
> +  // We can have undefined behaviour in JIT'ed code, e.g.
> +  // unreachable, and that causes lli to crash. Try to
> +  // instead intercept the signal and output a sane diagnostic.
> +  sys::Process::setSIGSEGVHandler(segfaultHandler);
> +
>    if (argc > 1)
>      ExitOnErr.setBanner(std::string(argv[0]) + ": ");
>
> Index: lib/Support/Windows/Process.inc
> ===================================================================
> --- lib/Support/Windows/Process.inc
> +++ lib/Support/Windows/Process.inc
> @@ -272,6 +272,9 @@
>    return std::error_code();
>  }
>
> +// FIXME: just a stub for now.
> +void Process::setSIGSEGVHandler(void (*handler)(int)) {}
> +
>  std::error_code Process::SafelyCloseFileDescriptor(int FD) {
>    if (::close(FD) < 0)
>      return std::error_code(errno, std::generic_category());
> Index: lib/Support/Unix/Process.inc
> ===================================================================
> --- lib/Support/Unix/Process.inc
> +++ lib/Support/Unix/Process.inc
> @@ -237,6 +237,10 @@
>    return std::error_code();
>  }
>
> +void Process::setSIGSEGVHandler(void (*handler)(int)) {
> +  signal(SIGSEGV, handler);
> +}
> +
>  std::error_code Process::SafelyCloseFileDescriptor(int FD) {
>    // Create a signal set filled with *all* signals.
>    sigset_t FullSet;
> Index: include/llvm/Support/Process.h
> ===================================================================
> --- include/llvm/Support/Process.h
> +++ include/llvm/Support/Process.h
> @@ -98,6 +98,9 @@
>    // components should not call this.
>    static std::error_code FixupStandardFileDescriptors();
>
> +  // This function sets a signal handler for SIGSEGV.
> +  static void setSIGSEGVHandler(void (*handler)(int));
> +
>    // This function safely closes a file descriptor.  It is not safe to
> retry
>    // close(2) when it returns with errno equivalent to EINTR; this is
> because
>    // *nixen cannot agree if the file descriptor is, in fact, closed when
> this
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161117/1c2d12e2/attachment.html>