On Fri, Dec 13, 2013 at 2:53 AM, Benjamin Smedberg
wrote:
>
> Also, we now have the ability to use DMD builds on Windows
DMD works on Windows debug builds, but doesn't currently work on opt
builds. But https://bugzilla.mozilla.org/show_bug.cgi?id=947117
(compile-time) and https://bugzilla.mozi
= Data and Background =
See, as some anecdotal evidence:
Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these
a lot.
dmajor tracked this down to our video implementation creating many
threads, each of which has an x86 stack as well as a 1MB memory
reservation for the wow6
- Original Message -
> From: "Bas Schouten"
> To: dev-platform@lists.mozilla.org
> Cc: "David Major" , "Nathan Froyd" ,
> "Firefox Dev"
> Sent: Tuesday, November 26, 2013 1:15:44 AM
> Subject: Re: Reacting more strongly to
Jeff Gilbert schrieb:
A 64-bit build would, but we "don't ship" those.
A win64 machine running a 32-bit program can have 4GB of VM, though.
OK, just wanted to make sure. Benjamin looked at 25.0 release data,
AFAIK, so that's of course only 32bit, but if we look at Nightly data, I
think a sign
Reacting more strongly to low-memory situations in Firefox 25
Benjamin Smedberg schrieb:
> On 11/25/13 8:15 PM, Bas Schouten wrote:
>> I'm a little confused, when I force OOM my firefox build on 64-bit
>> windows it -definitely- goes down before it reaches more than 3GB of
>
Benjamin Smedberg schrieb:
On 11/25/13 8:15 PM, Bas Schouten wrote:
I'm a little confused, when I force OOM my firefox build on 64-bit
windows it -definitely- goes down before it reaches more than 3GB of
working set. Am I missing something here?
I think so. I did not mention working set at all.
On 11/25/13 11:02 AM, Benjamin Smedberg wrote:
== Regression ranges ==
Some of the issues appear to be recently introduced in Firefox 25. We
need to jump on regression ranges ASAP. I could really use help working
with users such as those identified at the top of this message to see if
there are
On 11/25/13 8:15 PM, Bas Schouten wrote:
I'm a little confused, when I force OOM my firefox build on 64-bit
windows it -definitely- goes down before it reaches more than 3GB of
working set. Am I missing something here?
I think so. I did not mention working set at all. I am merely
calculating w
On Tue, Nov 26, 2013 at 4:02 AM, Benjamin Smedberg
wrote:
> In crashkill we have been tracking crashes that occur in low-memory
> situations for a while. However, we are seeing a troubling uptick of issues
> in Firefox 23 and then 25. I believe that some people may not be able to use
> Firefox bec
- Original Message -
> From: "Benjamin Smedberg"
> To: dev-platform@lists.mozilla.org, "Bas Schouten" ,
> "David Major" ,
> "Nathan Froyd" , "Firefox Dev"
> Sent: Monday, November 25, 2013 5:02:50 PM
> Su
On Mon, Nov 25, 2013 at 12:02:50PM -0500, Benjamin Smedberg wrote:
> Note that in many cases, the user hasn't actually run out of memory:
> they have plenty of physical memory and page file available. In most
> cases they also have enough available VM space! Often, however, this
> VM space is fragm
It seems that the 12MB reservation was aborting due to an invalid parameter.
I've filed bug 943051.
- Original Message -
From: "Benjamin Smedberg"
To: "Ehsan Akhgari" , dev-platform@lists.mozilla.org
Sent: Monday, November 25, 2013 9:18:02 AM
Subject: Re: Reac
On 11/25/13 1:31 PM, Ryan VanderMeulen wrote:
What does the OOM rate of 32bit builds on Win64 have to do with whether
or not making 64bit Firefox builds would help?
I think Benjamin's point was that only about 1/4 of the OOM crashes were
on Win64 [1]. The rest were on Win32, and hence would n
On 11/25/2013 1:26 PM, Benjamin Smedberg wrote:
This is an analysis of the crash reports from a particular day, so it's
almost all going to be 32-bit Firefox because that's the only thing we
release. 64-bit Firefox Nightly crashes due to OOM would be lumped into
the OOM-win64 bucket in the analys
On 11/25/2013 1:09 PM, Ryan VanderMeulen wrote:
So we're clear, this analysis is of 32bit Firefox builds running a
64bit Windows OS, right? So the process is still limited to 4GB of
address space. Wouldn't a native 64bit Firefox build have
significantly higher address space available to it?
T
On 11/25/2013 12:02 PM, Benjamin Smedberg wrote:> Because one of the
long-term possibilities discussed for solving this
> issue is releasing a 64-bit version of Firefox, I additionally broke
> down the "OOM" crashes into users running a 32-bit version of Windows
> and users running a 64-bit versi
On 11/25/2013 12:02 PM, Benjamin Smedberg wrote:
Because one of the long-term possibilities discussed for solving this
issue is releasing a 64-bit version of Firefox, I additionally broke
down the "OOM" crashes into users running a 32-bit version of Windows
and users running a 64-bit version of W
On 11/25/2013 12:11 PM, Ehsan Akhgari wrote:
Do we know how much memory we tend to use during the minidump
collection phase?
No, we don't. It seems that the Windows code maps all of the DLLs into
memory again in order to extract information from them.
Does it make sense to try to reserve an
On 2013-11-25 12:02 PM, Benjamin Smedberg wrote:
Unfortunately, often when we are out of memory crash reports come back
as empty minidumps (because the crash reporter has to allocation memory
and/or VM space to create minidumps). We believe that most of the
empty-minidump crashes present on crash
In crashkill we have been tracking crashes that occur in low-memory
situations for a while. However, we are seeing a troubling uptick of
issues in Firefox 23 and then 25. I believe that some people may not be
able to use Firefox because of these bugs, and I think that we should be
reacting more
20 matches
Mail list logo