Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

[Filip Pizlo]

Makes sense to me.

-Filip


> On Feb 8, 2016, at 12:33 PM, Mark Lam  wrote:
> 
> A store to 0xbbadbeef will still require the use of a register (at least on 
> ARM).  The breakpoint instruction uses no registers (hence, we don’t have to 
> choose which register to sacrifice).  We can still identify the crash as an 
> assertion by looking fro the EXC_BREAKPOINT instead of the 0xbbadbeef address.
> 
> Mark
> 
> 
>> On Feb 8, 2016, at 12:14 PM, Filip Pizlo  wrote:
>> 
>> 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  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

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

[Mark Lam]

A store to 0xbbadbeef will still require the use of a register (at least on 
ARM).  The breakpoint instruction uses no registers (hence, we don’t have to 
choose which register to sacrifice).  We can still identify the crash as an 
assertion by looking fro the EXC_BREAKPOINT instead of the 0xbbadbeef address.

Mark


> On Feb 8, 2016, at 12:14 PM, Filip Pizlo  wrote:
> 
> 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  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

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

[Filip Pizlo]

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

[webkit-dev] Change WTFCrash to not trash the crash site register state.

[Mark Lam]

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