Re: All about crashes

On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek wrote: > BugHunter[1] attempts to reproduce crashes from crash-stats by loading > the URLs from the crash reports, which is sometimes successful. > Of note, BugHunter also uses both debug and AddressSanitizer builds, which

Re: All about crashes

On Jun 3, 2016, at 8:53 AM, Ted Mielczarek wrote: > On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote: >> - Making it so that certain kinds of defects still happen but they are >> safer. >> For instance, in C writing dereferencing past the end of an array is >>

Re: All about crashes

I think that the ADI data comes from the blocklist ping which includes OS version (possibly Windows service pack as well). Robert On Fri, Jun 3, 2016 at 7:02 AM, Ted Mielczarek wrote: > On Tue, May 24, 2016, at 04:58 PM, Lawrence Mandel wrote: > > "Improve ranking of crash

Re: All about crashes

On Tue, May 24, 2016, at 04:58 PM, Lawrence Mandel wrote: > "Improve ranking of crash clusters." > > I think this is weighting or estimating impact of a crash instead of > volume > of submissions, which is how we have historically processed the clusters. > Severity is one component with startup

Re: All about crashes

On Wed, May 25, 2016, at 01:47 AM, Eric Rahm wrote: > Details on using rr to debug crashes would certainly be nice. In my experience, if a crash is reproducible it's generally straightforward to fix. rr could be useful if a crash is hard to reproduce or intermittent, but once a developer can

Re: All about crashes

On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote: > - Making it so that certain kinds of defects still happen but they are > safer. > For instance, in C writing dereferencing past the end of an array is > undefined behavior and may well cause something horrible, in Python > you get an

Re: All about crashes

About: > Additionally it would be great to see information on handling OOMs (large > and small) as those are our top crashers, and if anything I think project > uptime should be focusing on mitigating them. Fixing null derefs for a few > hundred users is nice, but fixing OOMs for tens of

Re: All about crashes

On Wed, May 25, 2016 at 9:45 PM, Nicholas Nethercote wrote: > On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel wrote: >> "Crashes are caused by defects" >> >> Reading this I think it implies defects in Firefox. This is not always the >> case. Crashes

Re: All about crashes

On Thu, May 26, 2016 at 1:06 PM, Lawrence Mandel wrote: > > > The aim is to make it much easier to handle intermittent test failures. > Crashes may be possible as well. > > The project is not yet well defined. Jonathan Griffin is working on this > with his team with the

Re: All about crashes

> > "Improve reproducibility of these crashes. > > > > Use rr to record crashes so they can be played back reliably." > > > > We're going to spin up a project to work on debugging in automation. > We've > > talked about having the ability to run a test until it fails and pause at > > that point. I

Re: All about crashes

On Wed, May 25, 2016 at 3:47 PM, Eric Rahm wrote: > Thanks for putting this together! > > It would be nice to see some consolidated details on how to investigate > crashes, ie loading minidumps in Visual Studio, interpreting results, > figuring out when VS is lying to you and

Re: All about crashes

On Thu, May 26, 2016 at 1:59 AM, Eric Rescorla wrote: >> >>> Under "Ways to prevent" you suggest >>> "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, >>> using smart pointers, etc. >>> >>> This may prevent crashes in the narrow sense that it prevents

Re: All about crashes

On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel wrote: > > Wasn't sure how you wanted feedback. Here's some in email form. Email is great, thank you. > "Crashes are caused by defects" > > Reading this I think it implies defects in Firefox. This is not always the > case.

Re: All about crashes

On 5/25/16 2:53 PM, Tobias B. Besemer wrote: Yes, but aren't the most OOM crashes from Win systems with 32bit FF and no E10s? My point is that the right solution to OOM crashes taking down the UI is to finally ship e10s, not build a complicated system to do something akin to e10s in

Re: All about crashes

On Wed, May 25, 2016 at 8:59 AM, Eric Rescorla wrote: > It's not a matter of defects versus non-defects. It's a matter of abnormal > program > termination versus non-termination. > Great clarification - thanks for explaining! ___

Re: All about crashes

On 5/25/16 1:37 PM, Tobias B. Besemer wrote: What about "crashing" all tabs (remove them from mem and show a error msg in them) That's precisely what a content process OOM does in multiprocess Firefox. -Boris ___ dev-platform mailing list

Re: All about crashes

On Wed, May 25, 2016 at 8:53 AM, Steve Fink wrote: > On 05/25/2016 06:09 AM, Eric Rescorla wrote: > >> Under "Ways to prevent" you suggest >> "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, >> using smart pointers, etc. >> >> This may prevent crashes

Re: All about crashes

On 05/25/2016 06:09 AM, Eric Rescorla wrote: Under "Ways to prevent" you suggest "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, using smart pointers, etc. This may prevent crashes in the narrow sense that it prevents SEGVs, etc. but it does not make runtime errors

Re: All about crashes

Am Dienstag, 24. Mai 2016 06:56:54 UTC+2 schrieb Nicholas Nethercote: > Greetings, > > I've written a document called "All about crashes" which I've put on > the Project Uptime wiki: > > https://wiki.mozilla.org/Platform/Uptime#All_about_crashes > > It's a

Re: All about crashes

Crashes that are charted here lead to disabling of graphics acceleration for these users, until next Firefox (or new graphics driver.) So, we trade them one startup crash right after installation, for multiple crashes during the usage of video or graphics features. — - Milan > On May 24,

Re: All about crashes

minate a large class of crashes, but they don't make them impossible. -Ekr On Mon, May 23, 2016 at 9:56 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > Greetings, > > I've written a document called "All about crashes" which I've put on > the Project Uptime wi

Re: All about crashes

Thanks for putting this together! It would be nice to see some consolidated details on how to investigate crashes, ie loading minidumps in Visual Studio, interpreting results, figuring out when VS is lying to you and what disassembly to look at. I think there's some great institutional knowledge

Re: All about crashes

On 5/25/16 12:05 AM, Tobias B. Besemer wrote: Why are there so many crashes on Windows and so less on Linux ??? Mostly because there are so many more people running Firefox on Windows than on Linux... -Boris ___ dev-platform mailing list

Re: All about crashes

..@gmail.com> wrote: > Greetings, > > I've written a document called "All about crashes" which I've put on > the Project Uptime wiki: > > https://wiki.mozilla.org/Platform/Uptime#All_about_crashes > > It's about all the different ways we can discover, diagnose, and

All about crashes

Greetings, I've written a document called "All about crashes" which I've put on the Project Uptime wiki: https://wiki.mozilla.org/Platform/Uptime#All_about_crashes It's about all the different ways we can discover, diagnose, and address crashes. It's intended to be a comprehensive,