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
I also found this:
https://support.mozilla.org/en-US/kb/contributors-crash-course
Which is similar to the first one, though presented in more of a
tutorial style, and lacking screenshots. Both of them describe the
meaning of individual fields, which would be better to have in
crash-stats itself, s
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
Bug 1275439 just landed on inbound, which renames the logging
specifier environment variable from MOZ_LOG_MODULES to just MOZ_LOG,
which is a lot less typing.
MOZ_LOG_FILE for directing logging output to a file remains the same.
Both MOZ_LOG_MODULES and NSPR_LOG_MODULES are still accepted, but
us
> Could the lack of failure emails be specific to taskcluster jobs?
https://bugzilla.mozilla.org/show_bug.cgi?id=1275774
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Wed, May 25, 2016 at 10:16:41AM -0400, Benjamin Smedberg wrote:
> On Thu, May 19, 2016 at 5:34 PM, Patrick McManus
> wrote:
>
> >
> > I’m not sure how to compare the size of the populations impacted by the
> > crash vs the size of the population impacted by the SSE dependency. My
> > intuition
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
I thought this was already asked and answered, but just to be clear.
We are not going to make any changes to the ESR schedule or make Firefox 48
any kind of long-term release. The development costs of maintaining another
branch are high, and not something we're willing to pay.
--BDS
On Tue, May
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
In general, the update pattern of these users matches the rest of our
population. They have updates turned on and generally are running a new
version.
That is true of populations we've looked at including WinXP (and WinXPSP2)
and MacOS. I'm not sure if we looked at that specifically for the SSE2
c
We did this for SSE2 ([1] is a chronicle of the first time I looked into
it) but I didn't do it for SSE (at the time, I just thought we'd already
required it).
The population is so small, it is difficult to speak with any authority. It
does appear as though roughly half of the !hasSSE population a
On 2016-05-25 2:04 AM, Eric Rahm wrote:
So my question is: How many of these users are actively
updating? I think this would be useful in making decisions on what support
to deprecate.
You should come to the "Accessing Data @ Mozilla" elective in London.
It'll be a whole series of lightning talk
On Thu, May 19, 2016 at 5:34 PM, Patrick McManus
wrote:
>
> I’m not sure how to compare the size of the populations impacted by the
> crash vs the size of the population impacted by the SSE dependency. My
> intuition says the no-SSE population is very small and we might be better
> off overall wi
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 about all the different ways we can disco
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
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 that lead to program shutdown
impossible. To take
23 matches
Mail list logo
