[webkit-dev] Terminate handler for WebKit

[JF Bastien]

On Fri, Sep 9, 2016 at 10:14 AM, Michael Catanzaro <mcatanzaro at igalia.com>
wrote:

> Hi,
>
> The GTK+ port currently has an interesting web process crash on exit:
>
> pure virtual method called
> terminate called without an active exception
>
> I found the easiest way to debug it was to rebuild with a terminate
> handler set:
>
>     std::set_terminate([] {
>         CRASH();
>     });
>
> Even if such issues are very rare, I think it makes sense to set this
> up always, since a simple backtrace is a lot better than nothing in
> such cases. Are there any objections to always setting this terminate
> handler? For my debugging today, I put it in
> WebKit::ChildProcess::initialize, which seems like a decent place, but
> maybe not the best place. Are there any other suggestions for where to
> put this code? I presume this would be desired for all ports, but we
> could certainly do it somewhere platform-specific if that's not the
> case.
>

I don't think it's a great idea because:

   - The state of the stack when std::terminate is called is implementation
   defined (it could be unwound, unwound partially, or not unwound at all).
   - std::terminate can be called from atexit or at_quick_exit which means
   that global state can be partially broken.
   - CRASH sometimes behaves in a manner which will cause signals to be
   generated, and installSignalHandlersForFatalErrors registers signal
   handlers (which sometimes calls dumpBacktraceSignalHandler which then calls
   exit, leading us back to atexit).

The chance for undefined behavior, weirdly circular call graphs,
exploitable behavior, or all three, seems pretty high here and very
dependent on configuration at compile-time.

JF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160909/06becc7f/attachment.html>