I like this idea. I think even doing what JF suggested could be really nice for
suspected crashes. That way the register state would just tell us the reason.
If we do log, I think we should use WTFLogAlways instead of dataLog, because I
think that does show up in some crash logs (but I could be wrong about this,
I’m not 100% sure).
- Saam
> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen <gga...@apple.com> wrote:
>
> I’ve lost countless hours to investigating CrashTracers that would have been
> easy to solve if I had access to register state.
>
> I also want the freedom to add RELEASE_ASSERT without ruining performance due
> to bad register allocation or making the code too large to inline. For
> example, hot paths in WTF::Vector use RELEASE_ASSERT.
>
> Is some compromise solution possible?
>
> Some options:
>
> (1) Add a variant of RELEASE_ASSERT that takes a string and logs.
>
> (2) Change RELEASE_ASSERT to do the normal debug ASSERT thing in Debug
> builds. (There’s not much need to preserve register state in debug builds.)
>
> Geoff
>
>> On Feb 22, 2017, at 11:09 AM, Filip Pizlo <fpi...@apple.com> wrote:
>>
>> I disagree actually. I've lost countless hours to converting this:
>>
>> RELEASE_ASSERT(blah)
>>
>> into this:
>>
>> if (!blah) {
>> dataLog("Reason why I crashed");
>> RELEASE_ASSERT_NOT_REACHED();
>> }
>>
>> Look in the code - you'll find lots of stuff like this.
>>
>> I don't think analyzing register state at crashes is more important than
>> keeping our code sane.
>>
>> -Filip
>>
>>
>>> On Feb 21, 2017, at 5:56 PM, Mark Lam <mark....@apple.com> wrote:
>>>
>>> Oh yeah, I forgot about that. I think the register state is more important
>>> for crash analysis, especially if we can make sure that the compiler does
>>> not aggregate the int3s. I’ll explore alternatives.
>>>
>>>> On Feb 21, 2017, at 5:54 PM, Saam barati <sbar...@apple.com> wrote:
>>>>
>>>> I thought the main point of moving to SIGTRAP was to preserve register
>>>> state?
>>>>
>>>> That said, there are probably places where we care more about the message
>>>> than the registers.
>>>>
>>>> - Saam
>>>>
>>>>> On Feb 21, 2017, at 5:43 PM, Mark Lam <mark....@apple.com> wrote:
>>>>>
>>>>> Is there a reason why RELEASE_ASSERT (and friends) does not call
>>>>> WTFReportAssertionFailure() to report where the assertion occur? Is this
>>>>> purely to save memory? svn blame tells me that it has been this way
>>>>> since the introduction of RELEASE_ASSERT in r140577 many years ago.
>>>>>
>>>>> Would anyone object to adding a call to WTFReportAssertionFailure() in
>>>>> RELEASE_ASSERT() like we do for ASSERT()? One of the upside
>>>>> (side-effect) of adding this call is that it appears to stop the compiler
>>>>> from aggregating all the RELEASE_ASSERTS into a single code location, and
>>>>> this will help with post-mortem crash debugging.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> 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 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
