[webkit-dev] Terminate handler for WebKit

Michael Catanzaro mcatanzaro at igalia.com
Fri Sep 9 11:47:14 PDT 2016

On Fri, 2016-09-09 at 11:03 -0700, JF Bastien wrote:
>    - The state of the stack when std::terminate is called is
> implementation
>    defined (it could be unwound, unwound partially, or not unwound at
> all).

Hi, I think it's very unlikely to ever be unwound because we compile
with -fno-exceptions?

>    - std::terminate can be called from atexit or at_quick_exit which
> means
>    that global state can be partially broken.

In fact, that's exactly what's occurring in the crash that prompted me
to look into this.

>    - 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).

Hm, installSignalHandlersForFatalErrors is only called
from WTFInstallReportBacktraceOnCrashHook, which is not called from
anywhere on any port, so this can't happen.

Anyone know why we have these unused functions? Are they there to be
used in modified debug builds, or should they be removed?

> 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.

Maybe it makes sense to do this only in debug builds? I agree that
playing with undefined behavior doesn't seem wise, but in practice it
worked very well to get a backtrace for a bug that would otherwise be
difficult to debug.


More information about the webkit-dev mailing list