On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather than as a crash
report. This was the idea behind bug 1209131, which got pretty far along
but never made it to the finish line.
This would actually potentially even give us better information
than fork-and-crash, since we should be able to include JS
stacks in that setup too. We've never been able to do that in
ordinary crash reports, since breakpad doesn't know how to
unwind JS stacks, and we can't safely ask the JS runtime to do
it while we're crashing.
On Wed, Sep 19, 2018 at 5:05 PM Randell Jesup <rjesup.n...@jesup.org> wrote:
>On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote:
>> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
>> > While it may be the case that we may need to be more stable for
>> > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT
in our
>> > codebase is actually a guaranteed to never fail, so promoting them
all to
>> > be enabled in something like Nightly is extremely dangerous in terms
of the
>> > stability of Nightly for users who are trying to use the browser to
get
>> > their normal work done.
>>
>> If it's truly useful to know whether Nightly users are failing these
>> MOZ_ASSERT assertions, we could use Telemetry to report their failure
>> instead of crashing.>
>> (I wonder if we could collect all the same data, and use the same crash
reporting infrastructure, for non-crashing crash reports like this.)
>
>On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child,
>and continue in the parent process.
Oooh, tricky. (though threads aren't preserved in forks, but the
current thread's stack is, so if we care about all threads, we might
need to grab pointers to their stacks/etc and store pointers to the
stacks before fork()). But even without that it would be good.
And yes, we don't have to have it crash the browser (though if it later
crashes we'd want to know about assertions we'd hit). Telemetry isn't
quite appropriate for reporting it; it could however save a crash report
at ASSERT(), then (probably) disable MOZ_ASSERT reports and let the
browser continue (and it may well now really crash). This disabling
would avoid the cascade effect, but still get us crashreports. This
would be a bunch(?) of work in crashreporter - ted? It might be easy
invoke a crashreport sampling, and continue, but I suspect it's not, and
might be quite hard.
--
Randell Jesup, Mozilla Corp
remove "news" for personal email
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
Common sense is the collection of prejudices acquired by age 18.
--Albert Einstein
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
