Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

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.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

On Fri, 2016-09-09 at 10:47 -0700, Anders Carlsson wrote:
> On macOS and iOS, we already get this by setting
> NSApplicationCrashOnExceptions in our initialize function.
> 
> - Anders

OK, so we'd have to do it in ChildProcess::platformInitialize to not
disturb you then.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Anders Carlsson]

On macOS and iOS, we already get this by setting NSApplicationCrashOnExceptions 
in our initialize function.

- Anders

> On Sep 9, 2016, at 10:14 AM, Michael Catanzaro  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.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

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.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev