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
occasionally turns up some
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
>> undefined behavior and may w
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 clusters."
> >
> > I
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 cr
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 repro
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 e
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 thousands
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 are also the result of interactions with third
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 intention of getting starte
> > "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
On Wed, May 25, 2016 at 6:51 PM, Nicholas Nethercote wrote:
>
> >> I did not read that as making *all* defects impossible, rather that it
> was
> >> talking about preventing defects, and one such approach is to use a
> >> mechanism (Rust, smart pointers) that makes certain types of defects
> >> im
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 what disassembly to l
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 SEGVs, etc.
>>> but i
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. Crashes are also the re
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 single-pr
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!
___
dev-platform mailing l
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
dev-platf
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 in the narrow sense
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 tha
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
>
&
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, 2
liminate a large class of crashes, but they don't make them impossible.
-Ekr
On Mon, May 23, 2016 at 9:56 PM, Nicholas Nethercote wrote:
> Greetings,
>
> I've written a document called "All about crashes" which I've put on
> the Project Uptime wiki:
>
>
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 h
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
dev-platfo
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 wiki:
>
> https://wiki.mozilla.org/Platform/Uptime#All_about_crashes
>
> It's about all the d
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
26 matches
Mail list logo
