Found myself looking at this page today, which is now labeled as
potentially obsolete due to not having undergone any substantial changes
in many years. Could someone please look it over and let me know if it's
worth keeping or salvageable at least?
https://developer.mozilla.org/en-US/docs/Modular
Stack Overflow or other programmer discussion Q&A sites are probably
better venues for questions like this, such as under the stack overflow
service-worker tag, see:
http://stackoverflow.com/questions/tagged/service-worker . Being able
to browse the questions and answers of others may also help sh
On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert wrote:
>
> Perhaps this isn't meant for me then? I looked at the query from the
> first post, but it's just noise to me. If it included the file that it
> crashed from, it would suddenly be very useful, since it'd then be
> trivial to see if there's so
On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote
wrote:
> On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg
> wrote:
>> You shouldn't need to annotate the file/line separately, because that is
>> (or at least should be!) the top of the stack.
>
> Yes. Don't get hung up on the lack of annotat
On Wed, Jun 1, 2016 at 9:39 AM, Nicholas Nethercote
wrote:
>
> Yes. Don't get hung up on the lack of annotations. It isn't much of a
> problem; you can click through easily enough. I have filed bug 1277104
> to fix the handful of instances that are showing up in practice, but
> it'll only be a min
On Tue, May 31, 2016 at 05:01:34PM -0700, L. David Baron wrote:
> On Tuesday 2016-05-31 12:50 -0400, Benjamin Smedberg wrote:
> > It's likely that this particular report is running out of VM, yes. jemalloc
> > allocates new memory chunks in large blocks (1MB?), and with only 122MB of
> > VM it's li
On Tuesday 2016-05-31 12:50 -0400, Benjamin Smedberg wrote:
> It's likely that this particular report is running out of VM, yes. jemalloc
> allocates new memory chunks in large blocks (1MB?), and with only 122MB of
> VM it's likely that a lot of that is inaccessible, either because of
> fragmentati
On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew wrote:
>
> I took a quick look at a random one of these OOMs[1], and what strikes me
> about it is that according to the crash report:
>
> Total Virtual Memory2147352576
>
> Available Virtual Memory122331136
>
> Syste
On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg wrote:
> You shouldn't need to annotate the file/line separately, because that is
> (or at least should be!) the top of the stack.
Yes. Don't get hung up on the lack of annotations. It isn't much of a
problem; you can click through easily enough.
Heads up: we'll soon be dropping support for building mozilla-central with
VS2013. Bug 1186064 tracks and the patch has already received r+.
I'm going to wait a few days before landing because this could be
disruptive and I want to at least give a heads up before I create a fire.
Please install VS
Also, perhaps function name (__func__) or one of the pretty versions.
-Ekr
On Tue, May 31, 2016 at 1:20 PM, Jeff Gilbert wrote:
> On Tue, May 31, 2016 at 6:18 AM, Gabriele Svelto
> wrote:
> > On 31/05/2016 13:26, Gijs Kruitbosch wrote:
> >> We could do a find/replace of no-arg calls to a new
On Tue, May 31, 2016 at 6:18 AM, Gabriele Svelto wrote:
> On 31/05/2016 13:26, Gijs Kruitbosch wrote:
>> We could do a find/replace of no-arg calls to a new macro that uses
>> MOZ_CRASH with a boilerplate message, and make the argument non-optional
>> for new uses of MOZ_CRASH? That would avoid th
A few of these are in MediaFormatReader.
On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote
wrote:
> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
> 222 0.02 %
Fixed in bug 1068151.
> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
> requests)
How does performance compare to Chrome?
-Jeff
On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider
wrote:
> I intend to turn Canvas CSS/SVG filters on by default on all platforms. It
> has been developed behind the canvas.filters.enabled preference. Google's
> Chrome is already shipping this in v
"offline.html" does not appear to be in filesToCache that is passed to
cache.addAll().
On Mon, May 30, 2016, at 03:02 PM, Mohit Bajoria wrote:
> Hello
>
> There is offline.html page in repository. When there is no internet
> connection then it should show up reading from cache.
> Right now it doe
Agreed that all startup crashes are important. The reason I focused on the
MOZ_CRASHes is that this is where somebody explicitly said “this is as bad as
it gets, we must crash now”, and I’d like to look at those once in a while, and
see if that’s really the case. Because I certainly ran into c
It's likely that this particular report is running out of VM, yes. jemalloc
allocates new memory chunks in large blocks (1MB?), and with only 122MB of
VM it's likely that a lot of that is inaccessible, either because of
fragmentation or because sites are allocating VM blocks of less than 64k,
which
On May 31, 2016, at 2:22 , Nicholas Nethercote
wrote:
#2 is unannotated MOZ_CRASH() calls, i.e. there is no string
argument given. These are mostly OOMs, though there are a few
others in there. These ones should be annotated so they show up
separately.
I took a quick look at a random one of
You're assuming that this happens every time, instead of randomly. If you
add the time since last crash to your column list, you can see that this is
true in some cases and not others.
I changed your link a little:
* remove "moz crash reason exists" - any startup crash is a problem
* excluded con
On 5/30/16 12:55 PM, Kyle Huey wrote:
Segregating the thread-specific and thread-agnostic parts into
separate classes seems like a good idea.
Just to be clear, that's pretty much all internal stuff. From the
perspective of an API consumer (Gecko), there is really only the
thread-specific thi
By the way, this is the kiss of death query. MOZ_CRASH, start up, in safe
mode. We’re basically forcing these people away. There is nothing they can do
even if they really want to run Firefox (assuming this is a persistent start up
crash, of course.) The numbers aren’t high, and majority of
On 2016-05-31 2:22 AM, Nicholas Nethercote wrote:
9 MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
sAliveDisplayItemDatas->Contains(aData)) 263 0.02 %
This one is https://bugzilla.mozilla.org/show_bug.cgi?id=1141089 .
-Markus
___
dev-platform ma
On Tue, May 31, 2016 at 10:28 AM, Milan Sreckovic
wrote:
> On a side note, the one that stood out for me was a “TODO” one. A crash
> seems to be a wrong way to tag TODOs :)
>
FWIW, this appears to have been fixed last week:
https://hg.mozilla.org/mozilla-central/rev/a61e4c04aadb
__
We do have contacts. The more information we pass along about this crash
including how to avoid crashing if we know the better our chances of
success. What would you recommend that we tell IBM Rapport?
Sylvestre - Can you please pass along information about the crash?
Thanks,
Lawrence
On Tue, M
Hello
There is offline.html page in repository. When there is no internet
connection then it should show up reading from cache.
Right now it doesn't read from cache and doesn't show up.
On 31 May 2016 at 00:20, Ben Kelly wrote:
> On May 30, 2016 1:55 PM, "Mohit Bajoria" wrote:
> > Offline fa
Yes.
--BDS
On Sun, May 29, 2016 at 6:59 PM, Chris Pearce wrote:
> So, given that users won't be able to install Firefox on unsupported
> versions of MacOSX, and unsupported users won't be upgraded, can we proceed
> to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
> Firefox
You shouldn't need to annotate the file/line separately, because that is
(or at least should be!) the top of the stack.
FWIW, we are currently working on changing the signature for crashes with
an AbortMessage (those using NS_RUNTIMEABORT) so that the abort message is
part of the signature. After
We considered that for the graphics ones, but the line number doesn’t persist
between versions, so we weren’t sure how the search would find all the ones
that are the same, but on different line numbers in different versions. In the
end we settled on using unique strings (for the interesting on
I search for and track the ones that start with “GFX” (which is why we added
those prefixes, to make it easier to find them all.) Here’s a comment on the
top few of those:
#3 is bug 1254400, filed in March, fixed in May, uplifted to 47.
#12 is a collection of different crashes, with the same m
On 2016-05-31 9:27 AM, Gijs Kruitbosch wrote:
On 31/05/2016 07:22, Nicholas Nethercote wrote:
10 MOZ_CRASH(Using observer service off the main thread!) 223 0.02 %
This looked interesting to me, but it seems almost all of them are
caused by IBM Rapport which hooks into the process and call
On 31/05/2016 07:22, Nicholas Nethercote wrote:
10 MOZ_CRASH(Using observer service off the main thread!) 223 0.02 %
This looked interesting to me, but it seems almost all of them are
caused by IBM Rapport which hooks into the process and calls the
observer service off-main-thread. If so
On 31/05/2016 13:26, Gijs Kruitbosch wrote:
> We could do a find/replace of no-arg calls to a new macro that uses
> MOZ_CRASH with a boilerplate message, and make the argument non-optional
> for new uses of MOZ_CRASH? That would avoid the problem for new
> MOZ_CRASH() additions, which seems like it
On 31/05/2016 09:40, Nicholas Nethercote wrote:
On Tue, May 31, 2016 at 5:06 PM, Chris Peterson wrote:
#2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
given. These are mostly OOMs, though there are a few others in there.
These ones should be annotated so they show up sepa
On Tue, May 31, 2016 at 5:06 PM, Chris Peterson wrote:
>>
>> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
>> given. These are mostly OOMs, though there are a few others in there.
>> These ones should be annotated so they show up separately.
>
> MOZ_CRASH()'s explanation st
On 5/30/16 11:22 PM, Nicholas Nethercote wrote:
#2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
given. These are mostly OOMs, though there are a few others in there.
These ones should be annotated so they show up separately.
MOZ_CRASH()'s explanation string parameter is op
35 matches
Mail list logo
