I like this idea.  I’ve wanted this for a while.

Can you explain why your approach doesn’t inline a store to 0xbbadbeef, so that 
this aspect of the current behavior is preserved?

-Filip


> On Feb 8, 2016, at 11:55 AM, Mark Lam <mark....@apple.com> wrote:
> 
> Hi WebKit folks,
> 
> For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s 
> implementation into an inlined function that has a single inlined asm 
> statement that issues a breakpoint trap.  The intent is to crash directly in 
> the caller’s frame and preserve the register values at the time of the crash. 
>  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.
> 
> This is in contrast to the current implementation where WTFCrash() is a 
> function that calls a lot of handler / callback functions before actually 
> crashing.  As a result, by the time it crashes, the caller’s register values 
> has most likely been trashed by all the work that the WTFCrash and the 
> handlers / callbacks do.  The register values in the captured crash report 
> will, therefore, no longer be useful for crash site analysis. 
> 
> You can find the patch for this change at 
> https://bugs.webkit.org/show_bug.cgi?id=153996.  This change will only be 
> applied for non-debug OS(DARWIN) builds for now.  I’m leaving all other build 
> build configurations with the existing WTFCrash() implementation and behavior.
> 
> Does anyone have any opinion / feedback on this change?
> 
> Thanks.
> 
> Regards,
> Mark
> 
> _______________________________________________
> 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

Reply via email to