Changeset 196397 in webkit


Ignore:
Timestamp:
Feb 10, 2016, 3:02:24 PM (9 years ago)
Author:
mark.lam@apple.com
Message:

Changed WTFCrash to not trash the crash site register state.
https://bugs.webkit.org/show_bug.cgi?id=153996

Reviewed by Geoffrey Garen.

When doing post-mortem crash site analysis using data from crash reports, it is
immensely valuable to be able to infer the crashing program's state from the
register values at crash time. However, for RELEASE_ASSERT failures, we crash
using WTFCrash(), and WTFCrash() is currently implemented as a function call
that, in turn, calls a lot of other functions to do crash handling before
actually crashing. As a result, the register values captured in the crash
reports are not likely to still contain the values used by the caller function
that failed the RELEASE_ASSERT.

This patch aims to remedy this issue for non-debug builds on OS(DARWIN) ports.
It does so by changing WTFCrash() into an inlined function that has an inlined
asm statement to issues the CPU specific breakpoint trap instruction. As a
result, for non-debug OS(DARWIN) builds, crashes due to failed RELEASE_ASSERTs
will now show up in crash reports as crashing due to EXC_BREAKPOINT (SIGTRAP)
instead of a EXC_BAD_ACCESS (SIGSEGV) on address 0xbbadbeef.

For debug and non-DARWIN builds, WTFCrash() behavior currently remains unchanged.

  • wtf/Assertions.cpp:
  • wtf/Assertions.h:
Location:
trunk/Source/WTF
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WTF/ChangeLog

    r196315 r196397  
     12016-02-09  Mark Lam  <mark.lam@apple.com>
     2
     3        Changed WTFCrash to not trash the crash site register state.
     4        https://bugs.webkit.org/show_bug.cgi?id=153996
     5
     6        Reviewed by Geoffrey Garen.
     7
     8        When doing post-mortem crash site analysis using data from crash reports, it is
     9        immensely valuable to be able to infer the crashing program's state from the
     10        register values at crash time.  However, for RELEASE_ASSERT failures, we crash
     11        using WTFCrash(), and WTFCrash() is currently implemented as a function call
     12        that, in turn, calls a lot of other functions to do crash handling before
     13        actually crashing.  As a result, the register values captured in the crash
     14        reports are not likely to still contain the values used by the caller function
     15        that failed the RELEASE_ASSERT.
     16
     17        This patch aims to remedy this issue for non-debug builds on OS(DARWIN) ports.
     18        It does so by changing WTFCrash() into an inlined function that has an inlined
     19        asm statement to issues the CPU specific breakpoint trap instruction.  As a
     20        result, for non-debug OS(DARWIN) builds, crashes due to failed RELEASE_ASSERTs
     21        will now show up in crash reports as crashing due to EXC_BREAKPOINT (SIGTRAP)
     22        instead of a EXC_BAD_ACCESS (SIGSEGV) on address 0xbbadbeef.
     23
     24        For debug and non-DARWIN builds, WTFCrash() behavior currently remains unchanged.
     25
     26        * wtf/Assertions.cpp:
     27        * wtf/Assertions.h:
     28
    1292016-02-09  Csaba Osztrogonác  <ossy@webkit.org>
    230
  • trunk/Source/WTF/wtf/Assertions.cpp

    r195452 r196397  
    313313}
    314314
     315#if !defined(NDEBUG) || !OS(DARWIN)
    315316void WTFCrash()
    316317{
     
    327328#endif
    328329}
     330#endif // !defined(NDEBUG) || !OS(DARWIN)
    329331   
    330332void WTFCrashWithSecurityImplication()
  • trunk/Source/WTF/wtf/Assertions.h

    r187819 r196397  
    163163extern "C" {
    164164#endif
    165     WTF_EXPORT_PRIVATE NO_RETURN_DUE_TO_CRASH void WTFCrash();
     165#if defined(NDEBUG) && OS(DARWIN)
     166ALWAYS_INLINE NO_RETURN_DUE_TO_CRASH void WTFCrash()
     167{
     168    // Crash with a SIGTRAP i.e EXC_BREAKPOINT.
     169    // We are not using __builtin_trap because it is only guaranteed to abort, but not necessarily
     170    // trigger a SIGTRAP. Instead, we use inline asm to ensure that we trigger the SIGTRAP.
     171#if CPU(X86_64) || CPU(X86)
     172    asm volatile ("int3");
     173#elif CPU(ARM_THUMB2)
     174    asm volatile ("bkpt #0");
     175#elif CPU(ARM64)
     176    asm volatile ("brk #0");
     177#else
     178#error "Unsupported CPU".
     179#endif
     180    __builtin_unreachable();
     181}
     182#else
     183WTF_EXPORT_PRIVATE NO_RETURN_DUE_TO_CRASH void WTFCrash();
     184#endif
     185
    166186#ifdef __cplusplus
    167187}
Note: See TracChangeset for help on using the changeset viewer.