[webkit-dev] WTFCrash()

[Adrian Perez de Castro]

Hello,

Just a quick note below about the backtraces...

On Tue, 06 Mar 2018 23:09:18 -0600, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
 
> After [1], WTFCrash() is used only in debug builds on Darwin. For 
> Darwin release builds, inline assembly is used to trigger a SIGTRAP. I 
> experimented with this today and found it works quite badly on Linux, 
> somehow confusing gdb and clobbering the top frames of the stacktrace, 
> so I think we should leave that unchanged and keep it Darwin-only. So 
> this mail applies only to debug builds on Darwin, and to non-Darwin 
> ports.
> 
> Now, currently, WTFCrash() does three things:
> 
>  (1) Calls a user-configurable crash hook
>  (2) Print a low-quality backtrace to stderr
>  (3) Crash somehow:
>    - If ASAN is used, with __builtin_trap() (that's SIGILL on Linux 
> x86_64)
>    - Then with *(int *)(uintptr_t)0xbbadbeef = 0, which might fail to 
> crash if 0xbadbeef is a valid address, and is SIGSEGV otherwise
>    - Then with __builtin_trap() if COMPILER(GCC_OR_CLANG)
>    - Then with ((void(*)())0)() otherwise (presumably SIGSEGV or 
> SIGBUS, dunno)
> 
> This is all rather more complicated than it needs to be.
> 
> First off, the crash hook is (almost) unused and should simply be 
> removed, see [2].
> 
> Next, the low-quality backtrace. Does anyone think this is useful? [...]

In some cases I have worked with embedded devices where it was extremely
difficult to even run “gdbserver”, mainly due to memory constraints, and
having the limited backtrace from WTFCrash() can save the day in those
cases.

I think it's perfectly fine to skim over and ignore the backtraces
printed by WTFCrash() if one has a better way of debugging.

> [...] It's mainly annoying to me, [...]

This is not a good reason to remove them. Just don't use them and skip
reading them and you are done ;-)

> [...] because it's not anywhere near as good as a proper backtrace that
> shows stack members, [...]

True, but sometimes it's all we can have (see above), which is always
better than nothing.

> [...] it's mangled so function names are unnecessarily-difficult to read,

Pipe the output to “c++filt” and you will get back demangled names.
Nifty little tool :D

> [...] and it takes all of five seconds to get a much nicer one with
> modern Linux developer tools.

That is, *IF* one has access to modern developers tools.

> [...] If other developers like it, perhaps we could keep it for debug builds
> only, and skip right to the crashing in release builds? I suppose we could
> keep printing it always if there is desire to do this, because it has never
> caused any problems with Linux crash telemetry and doesn't seem to be
> harming anything, but otherwise my instinct is to simplify.

I would enable printing backtraces to -DENABLE_DEVELOPER_MODE=ON instead,
because they can be useful in release (well, or RelWithDebInfo) builds.

Cheers,


--
 Adrián 🎩
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180309/dcc8acd3/attachment.bin>