How badly out of date is this?

[Eric Shepherd]

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/Modularization_Techniques

If it's worth keeping, I'll move it to the Mozilla documentation area.
If not, the archival area.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Service Worker - Offline fallback not working

[Andrew Sutherland]

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 shed insight
on your problem.  dev-platform, as described at
https://www.mozilla.org/en-US/about/forums/#dev-platform, is for
discussion of the implementation of the underlying functionality in the
context of Gecko.  I had responded previously because I thought it might
be a simple thing where having someone else look at it helps and writing
these "sorry, you're in the wrong place" messages can take a while to
write and be frustrating to read.
 
When posting there, I'd suggest being very explicit about the exact
situation you're testing and what you're expecting in terms of success
or failure.  For example, seeing that you're using the gh-pages branch,
I tried accessing the page via the github.io url of
https://mbj36.github.io/My-Blog/ but that redirected to
http://mohitbajoria.com/ which, as a non-https origin (and apparently
not listening on the https port), is not eligible to use service workers
at all.  That may be your problem, or it could be something else.
 
It's probably worth experimenting with the devtools on a service-worker
enabled site such as https://www.pokedex.org/ that is known to work and
then comparing with your (test) site.  Also, instrumenting your service
worker with console.log/etc.
 
Andrew
 
 
On Tue, May 31, 2016, at 09:45 PM, Mohit Bajoria wrote:
> Hello
>
> I added "offline.html" in filesToCache but still the same problem
> arises. When i refresh the page in absence of internet connection
> "offline.html" doesn't show up.
>
> Github project link -
> https://github.com/mbj36/My-Blog/commits/gh-pages
>
> Please help
> Thanks
> Mohit
>
> On 31 May 2016 at 23:45, Andrew Sutherland
>  wrote:
>> "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 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 fallback event is not working.
>>  > > > Can anyone please let me know the error and help me solving
>>  > > > the issue ?
>>  > >
>>  > > Can you describe what you expect and what you are actually
>>  > > seeing happen?
>>  > >
>>  > > There is no "offline fallback event", so not sure exactly what
>>  > > you mean.
>>  > >
>>  > > Thanks.
>>  > >
>>  > > Ben
>>  > >
>> > ___
>>  > dev-platform mailing list
>>  > dev-platform@lists.mozilla.org
>>  > https://lists.mozilla.org/listinfo/dev-platform
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

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 something relevant to me.

Let's look at the top #3:


1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
129715  9.92 %

If you use your favourite source code search tool to look for
"Shutdown too long", you'll find that this crash is occurring in
toolkit/components/terminator/nsTerminator.cpp. For example, here's a
DXR link:

https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false

The line in question looks like this:

 MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");


2  MOZ_CRASH() 25987   1.99 %

This one matches all calls to MOZ_CRASH() that don't provide a string
parameter. Digging into these ones is slightly harder, requiring a new
search for bugs that have "moz crash reason" set to "MOZ_CRASH()":

https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature


3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %

Searching for "working D3D9 Compositor" identifies this one as coming
from gfx/layers/d3d9/CompositorD3D9.cpp.


And so on. Searching for strings in code is a useful technique in many
situations, I recommend it!


BTW, thank you to all those who have already looked through the list
and mentioned existing bugs and/or filed new bugs.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jeff Gilbert]

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 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 minor improvement.

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 something relevant to me.

As it stands now, the query alone doesn't seem useful to me. If it's
meant to be useful to developers who write MOZ_CRASHes, this is a
problem. If not, please ignore!

I would be extremely interested in MOZ_CRASHes and friends
automatically getting bugs filed and needinfo'd. An index of
crashes-by-file would get half-way there for me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

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 minor improvement.

Related: this is a common pattern:

  if (!cond) {
MOZ_CRASH();
  }

If you instead write this:

  MOZ_RELEASE_ASSERT(cond);

not only is it shorter and more readable, but the crash report will
automatically be annotated with "cond".

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Mike Hommey]

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 likely that a lot of that is inaccessible, either because of
> > fragmentation or because sites are allocating VM blocks of less than 64k,
> > which is the allocation resolution of Windows VM.
> > 
> > If you look at the raw dump tab, you'll see:
> > 
> > "largest_free_vm_block": "0xf" - which is 983040 bytes, less than 1MB.
> 
> Would it make sense for jemalloc to try allocating memory in smaller
> chunks when large ones aren't available?

The way jemalloc (currently) works doesn't allow that. Making chunks
smaller is one option. Future versions might even remove the notion of
chunks (https://github.com/jemalloc/jemalloc/issues/360)

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[L. David Baron]

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
> fragmentation or because sites are allocating VM blocks of less than 64k,
> which is the allocation resolution of Windows VM.
> 
> If you look at the raw dump tab, you'll see:
> 
> "largest_free_vm_block": "0xf" - which is 983040 bytes, less than 1MB.

Would it make sense for jemalloc to try allocating memory in smaller
chunks when large ones aren't available?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

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
>
> System Memory Use Percentage52
>
> Available Page File 4932567040
>
> Available Physical Memory   1790652416
>
> OOM Allocation Size 24
>
> it seems like the system is still some way from running out of memory.
> Available Virtual Memory is "only" 122MB, which admittedly isn't very much
> in present-day terms, but stillwhy can't we successfully allocate a
> 24-byte block? Can those 122MB really be _so_ fragmented?!

I looked at a bunch of these yesterday. It's pretty common for OOM to
occur when there is around 200--250 MiB of available virtual memory;
122 MB is probably lower than normal. As bsmedberg said, jemalloc uses
1 MiB chunks so the size of 24 is something of a red herring here.
(It's still useful in the sense that it's tiny, so making this
allocation fallible is unlikely to be helpful.)

More generally, I did a search yesterday of all our "OOM | small"
crashes for the past week. About 5% of them occur when the user has >
1 GiB of available virtual memory *and* > 1 GiB of available physical
memory, which is surprising. I would love to see a scatter plot
showing available physical memory vs. available virtual memory for all
our "OOM | small" crashes. bsmedberg, do we have tools to extract that
kind of data from crash-stats?

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

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. I have filed bug 1277104
to fix the handful of instances that are showing up in practice, but
it'll only be a minor improvement.

And adding more detail can be a hindrance. As others mentioned, if you
add the line number that will change over time, which means that
related crashes will be grouped separately in this search. A more
extreme example of this is NS_RUNTIME_ABORT's AbortMessage, which
includes the *Process ID*. From a crash aggregation POV this is a
disaster, because it all but guarantees that no related crashes will
get clustered in this kind of search.

> 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 that works, we should probably do the same
> thing or something similar for the new MozCrashReason field. (I'm not sure
> why we used different field names for these.)

I tried doing a similar search for AbortMessage but I couldn't get it
to work. For example:

https://crash-stats.mozilla.com/search/?product=Firefox&abort_message=ABORT&_facets=abort_message&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=abort_message#facet-abort_message

Gives a table that looks like this:

Rank Abort message Count %
1 abort 20461 100.00 %
2 file 20148 98.47 %
3 line 13681 66.86 %
4 build 6974 34.08 %
5 builds 6744 32.96 %

Even ignoring the anti-clustering problems caused with the Process ID
(described above), it seems to be bucketing according to individual
words in the AbortMessage, rather than the entire AbortMessage. I
don't understand what's happening.



Anyway, can we just get rid of NS_RUNTIMEABORT? I count 308
occurrences of it in the code vs. 4064 for MOZ_CRASH.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dropping support for VS2013

[Gregory Szorc]

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 VS2015 in the next 48 hours to avoid a surprise the next
time you pull.

(We've previously recommended everyone install VS2015, so this announcement
should come as no surprise.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Eric Rescorla]

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 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 would be wise so the problem
> >> doesn't get worse? Or is it not worth even that?
> >
> > What about adding file/line number information? This way one could
> > always tell where it's coming from even if it doesn't have a descriptive
> > string.
>
> Agreed! These queries are much more useful if they have file names.
> Line numbers are a plus, but I agree that since these drift, they are
> not useful for collating. File names will generally not drift, and
> would make these queries much easier to grep for problems originating
> from code we're responsible for.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jeff Gilbert]

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 the problem for new
>> MOZ_CRASH() additions, which seems like it would be wise so the problem
>> doesn't get worse? Or is it not worth even that?
>
> What about adding file/line number information? This way one could
> always tell where it's coming from even if it doesn't have a descriptive
> string.

Agreed! These queries are much more useful if they have file names.
Line numbers are a plus, but I agree that since these drift, they are
not useful for collating. File names will generally not drift, and
would make these queries much easier to grep for problems originating
from code we're responsible for.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Ralph Giles]

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) 110 0.01 %

We think this is fixed in bug 1276495, but it's too soon to confirm.

> 39 MOZ_RELEASE_ASSERT(!mVideo.mDecodingRequested) (Reset must have
> been called)17  0.00 %

Fixed in bug 1272964.


And in GraphDriver,

> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 %

it looks like this could propagate an error instead. I filed bug 1277037.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CSS/SVG filters

[Jeff Muizelaar]

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 version 52.
>
> Related bugs:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>
> Specification:
>
> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Service Worker - Offline fallback not working

[Andrew Sutherland]

"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 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 fallback event is not working.
> > > Can anyone please let me know the error and help me solving the issue ?
> >
> > Can you describe what you expect and what you are actually seeing happen?
> >
> > There is no "offline fallback event", so not sure exactly what you mean.
> >
> > Thanks.
> >
> > Ben
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

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 code that was more 
of the “this should never happen, and if it does I don’t understand why” with 
MOZ_CRASHes in it,  and that can be improved...
—
- Milan



> On May 31, 2016, at 12:28 , Benjamin Smedberg  wrote:
> 
> 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 content and plugin process crashes - those aren't "startup" 
> crashes the same way, and they don't prevent users from updating or disabling 
> addons
> * added facets on the crash reason and the abort message
> * added the time-since-last-crash to the column list
> 
> The top things on this list are:
> 
> by signature:
> 
> __RtlUserThreadStart | _RtlUserThreadStart (maybe bug 1164826 
>  , need to dig to 
> separate by this DLL)
> mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet (longstanding 
> problem, perhaps evidence of a bad update or install - bug 1194856 
> )
> OOM | small - this is surprising and disturbing to me - I wonder how much of 
> this is actually OOM and how much is memory corruption. I filed bug 1276993 
> as a work item for this.
> EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER - again 
> normally OOM but I wouldn't expect that at startup
> 
> 
> --BDS
> 
> 
> On Tue, May 31, 2016 at 11:52 AM, Milan Sreckovic  > wrote:
> 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 them 
> are OOMs, but I still feel like this query should never have things in it.  
> (Randomly picked 8 seconds, I know that some consider it a start up crash if 
> it crashes much later than that.)
> 
> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
>  
> 
> 
> It’s also interesting to extend the query to specify the amount of memory the 
> machine has - how do we get an OOM on startup when the users have 2GB of RAM?
> —
> - Milan
> 
> 
> 
> >
> >> On May 31, 2016, at 2:22 , Nicholas Nethercote  >> > wrote:
> >>
> >> Hi,
> >>
> >> Here is a crash-stats search that shows all the crash reports in the
> >> past 7 days that have a "MozCrashReason" field -- which means they
> >> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> >> aggregated) by that field:
> >>
> >> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> >>  
> >> 
> >>
> >> I've included the output below. (Apologies if it gets munged when the
> >> email is processed; just click on the link above to see the live
> >> list.)
> >>
> >> #1 by a long way is shutdown hangs. No great surprise.
> >>
> >> #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.
> >>
> >> From #3 down we have smaller numbers, but many of them are still
> >> non-trivial, and a lot of them are probably indicative of problems
> >> that are very easy to fix if the right person sees them. Please take a
> >> look through the list to see if any of them are familiar to you.
> >>
> >> (If you're wondering why I made this search... I've found that many
> >> crash reports lack enough data to be actionable -- especially those
> >> involving crashes caused by bad memory accesses. So it's worth
> >> focusing to so

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 is the allocation resolution of Windows VM.

If you look at the raw dump tab, you'll see:

"largest_free_vm_block": "0xf" - which is 983040 bytes, less than 1MB.

--BDS



On Tue, May 31, 2016 at 12:37 PM, Jonathan Kew  wrote:

> 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 these OOMs[1], and what strikes me
> about it is that according to the crash report:
>
> Total Virtual Memory2147352576
>
> Available Virtual Memory122331136
>
> System Memory Use Percentage52
>
> Available Page File 4932567040
>
> Available Physical Memory   1790652416
>
> OOM Allocation Size 24
>
> it seems like the system is still some way from running out of memory.
> Available Virtual Memory is "only" 122MB, which admittedly isn't very much
> in present-day terms, but stillwhy can't we successfully allocate a
> 24-byte block? Can those 122MB really be _so_ fragmented?!
>
> JK
>
> [1]
> https://crash-stats.mozilla.com/report/index/e59d2f18-2131-4f24-9f43-7038b2160524
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jonathan Kew]

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 these OOMs[1], and what strikes 
me about it is that according to the crash report:


Total Virtual Memory2147352576

Available Virtual Memory122331136

System Memory Use Percentage52

Available Page File 4932567040

Available Physical Memory   1790652416

OOM Allocation Size 24

it seems like the system is still some way from running out of memory. 
Available Virtual Memory is "only" 122MB, which admittedly isn't very 
much in present-day terms, but stillwhy can't we successfully 
allocate a 24-byte block? Can those 122MB really be _so_ fragmented?!


JK

[1] 
https://crash-stats.mozilla.com/report/index/e59d2f18-2131-4f24-9f43-7038b2160524

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 content and plugin process crashes - those aren't "startup"
crashes the same way, and they don't prevent users from updating or
disabling addons
* added facets on the crash reason and the abort message
* added the time-since-last-crash to the column list

The top things on this list are:

by signature:

__RtlUserThreadStart | _RtlUserThreadStart (maybe bug 1164826
 , need to dig to
separate by this DLL)
mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet (longstanding
problem, perhaps evidence of a bad update or install - bug 1194856
)
OOM | small - this is surprising and disturbing to me - I wonder how much
of this is actually OOM and how much is memory corruption. I filed bug
1276993 as a work item for this.
EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER - again
normally OOM but I wouldn't expect that at startup


--BDS


On Tue, May 31, 2016 at 11:52 AM, Milan Sreckovic 
wrote:

> 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 them are OOMs, but I still feel like this query should never
> have things in it.  (Randomly picked 8 seconds, I know that some consider
> it a start up crash if it crashes much later than that.)
>
>
> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
>
> It’s also interesting to extend the query to specify the amount of memory
> the machine has - how do we get an OOM on startup when the users have 2GB
> of RAM?
> —
> - Milan
>
>
>
> >
> >> On May 31, 2016, at 2:22 , Nicholas Nethercote 
> wrote:
> >>
> >> Hi,
> >>
> >> Here is a crash-stats search that shows all the crash reports in the
> >> past 7 days that have a "MozCrashReason" field -- which means they
> >> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> >> aggregated) by that field:
> >>
> >>
> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> >>
> >> I've included the output below. (Apologies if it gets munged when the
> >> email is processed; just click on the link above to see the live
> >> list.)
> >>
> >> #1 by a long way is shutdown hangs. No great surprise.
> >>
> >> #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.
> >>
> >> From #3 down we have smaller numbers, but many of them are still
> >> non-trivial, and a lot of them are probably indicative of problems
> >> that are very easy to fix if the right person sees them. Please take a
> >> look through the list to see if any of them are familiar to you.
> >>
> >> (If you're wondering why I made this search... I've found that many
> >> crash reports lack enough data to be actionable -- especially those
> >> involving crashes caused by bad memory accesses. So it's worth
> >> focusing to some degree on the crash reports that are more likely to
> >> be actionable, and places where we deliberately abort are an obvious
> >> case.)
> >>
> >> Nick
> >>
> >>
> >> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
> >>129715  9.92 %
> >> 2  MOZ_CRASH() 25987   1.99 %
> >> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
> >> 21040.16 %
> >> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13
> %
> >> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06
> %
> >> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> >> collector found more references to an object than its refcount)509
> >>0.04 %
> >> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
> >> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
> >> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
> >> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
> >> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02
> %
> >> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
> >>222 0.02 %
> >> 12 MOZ_CRASH(GFX_CRASH)215 0.02 %
> >>

Re: How to name our JSContext getter(s): let the bikeshed begin

[Boris Zbarsky]

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 thing in spidermonkey API.


Put another way, as far as I can tell, SpiderMonkey will continue to 
have an API where there is some thing (name not clear yet, but currently 
it's called JSRuntime) that maps to some specific thread of the 
embedding.  That thread is the only embedder thread allowed to touch 
anything to do with that JSRuntime.  SpiderMonkey will internally create 
various helper threads (e.g. for JIT compilation) which may touch some 
things that may or may not live on JSRuntime; this is the part still 
being decided.  But from the point of view of the embedding, all that 
stuff doesn't even exist.



Given that it only makes sense to use a thread-specific object on that
thread, and it only makes sense to get the thread-agnostic object here
*from TLS* on one thread, I don't think we need any "thread" naming.


OK.  So what do you propose we name things?

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

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 them are OOMs, but 
I still feel like this query should never have things in it.  (Randomly picked 
8 seconds, I know that some consider it a start up crash if it crashes much 
later than that.)

https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

It’s also interesting to extend the query to specify the amount of memory the 
machine has - how do we get an OOM on startup when the users have 2GB of RAM?
—
- Milan



> 
>> On May 31, 2016, at 2:22 , Nicholas Nethercote  
>> wrote:
>> 
>> Hi,
>> 
>> Here is a crash-stats search that shows all the crash reports in the
>> past 7 days that have a "MozCrashReason" field -- which means they
>> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
>> aggregated) by that field:
>> 
>> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
>> 
>> I've included the output below. (Apologies if it gets munged when the
>> email is processed; just click on the link above to see the live
>> list.)
>> 
>> #1 by a long way is shutdown hangs. No great surprise.
>> 
>> #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.
>> 
>> From #3 down we have smaller numbers, but many of them are still
>> non-trivial, and a lot of them are probably indicative of problems
>> that are very easy to fix if the right person sees them. Please take a
>> look through the list to see if any of them are familiar to you.
>> 
>> (If you're wondering why I made this search... I've found that many
>> crash reports lack enough data to be actionable -- especially those
>> involving crashes caused by bad memory accesses. So it's worth
>> focusing to some degree on the crash reports that are more likely to
>> be actionable, and places where we deliberately abort are an obvious
>> case.)
>> 
>> Nick
>> 
>> 
>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>>129715  9.92 %
>> 2  MOZ_CRASH() 25987   1.99 %
>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
>> 21040.16 %
>> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %
>> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06 %
>> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
>> collector found more references to an object than its refcount)509
>>0.04 %
>> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
>> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
>> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
>> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
>> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02 %
>> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
>>222 0.02 %
>> 12 MOZ_CRASH(GFX_CRASH)215 0.02 %
>> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread())   131 0.01 %
>> 14 MOZ_RELEASE_ASSERT(aMsg.priority() ==
>> IPC::Message::PRIORITY_NORMAL)120 0.01 %
>> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
>> refcount)   113 0.01 %
>> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
>> requests) 110 0.01 %
>> 17 MOZ_RELEASE_ASSERT(ok)  105 0.01 %
>> 18 MOZ_CRASH(GFX: D3D11 timeout)   99  0.01 %
>> 19 MOZ_CRASH(invalid process aSelector)73  0.01 %
>> 20 MOZ_CRASH(We lost the following char message)   58  0.00 %
>> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.)
>>53  0.00 %
>> 22 MOZ_CRASH(TODO: sourcebuffer was deleted from under us) 52
>>0.00 %
>> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL ||
>> NS_IsMainThread())  51  0.00 %
>> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device
>> reset)   45  0.00 %
>> 25 MOZ_RELEASE_ASSERT(isSystem)42  0.00 %
>> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41  0.00 %
>> 27 MOZ_CRASH(sandbox_init() failed)41  0.00 %
>> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor)  37  0.00 %
>> 29 MOZ_CRASH(GFX: Invalid D3D11 content device)33  0.00 %
>> 30 MOZ_CRASH(Initial length is too large)  30  0.00 %
>> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Markus Stange]

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 mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Ben Kelly]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Lawrence Mandel]

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, May 31, 2016 at 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 calls the observer service
> off-main-thread. If someone has contacts there, I guess we could tell them
> not to do that? :-\
>
>
> ~ Gijs
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Service Worker - Offline fallback not working

[Mohit Bajoria]

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 fallback event is not working.
> > Can anyone please let me know the error and help me solving the issue ?
>
> Can you describe what you expect and what you are actually seeing happen?
>
> There is no "offline fallback event", so not sure exactly what you mean.
>
> Thanks.
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

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 49 and just assume everywhere that MacOSX specific Gecko code is
> running on 10.9 or later?
>
>
>
> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:
>
> > On Thu, May 26, 2016 at 3:37 PM, L. David Baron 
> wrote:
> >
> > > There's a screenshot in:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> > > (which is the bug that made the necessary changes for the Mac OS X
> > > support change in Firefox 49).
> >
> > Ah, that's great. Thanks!
> >
> >  -r
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 that works, we should probably do the same
thing or something similar for the new MozCrashReason field. (I'm not sure
why we used different field names for these.)

--BDS

On Tue, May 31, 2016 at 9: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 the problem for new
> > MOZ_CRASH() additions, which seems like it would be wise so the problem
> > doesn't get worse? Or is it not worth even that?
>
> What about adding file/line number information? This way one could
> always tell where it's coming from even if it doesn't have a descriptive
> string.
>
>  Gabriele
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

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 ones, at least.)
—
- Milan



> On May 31, 2016, at 9:18 , 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 the problem for new
>> MOZ_CRASH() additions, which seems like it would be wise so the problem
>> doesn't get worse? Or is it not worth even that?
> 
> What about adding file/line number information? This way one could
> always tell where it's coming from even if it doesn't have a descriptive
> string.
> 
> Gabriele
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

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 message, but it will 
only crash in nightlies and auroras; in betas and releases, it turns into a 
warning message, and telemetry gets sent that the “crash was avoided, but you 
really should try to fix this”.

#18 has been tracked since February 2015, bug 1133623, and is related to 
recovering from driver resets.  Long haul on this one, that’s why we have 
“recover from driver resets” as a 2016H1 goal.

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 :)

—
- Milan



> On May 31, 2016, at 2:22 , Nicholas Nethercote  wrote:
> 
> Hi,
> 
> Here is a crash-stats search that shows all the crash reports in the
> past 7 days that have a "MozCrashReason" field -- which means they
> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> aggregated) by that field:
> 
> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> 
> I've included the output below. (Apologies if it gets munged when the
> email is processed; just click on the link above to see the live
> list.)
> 
> #1 by a long way is shutdown hangs. No great surprise.
> 
> #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.
> 
> From #3 down we have smaller numbers, but many of them are still
> non-trivial, and a lot of them are probably indicative of problems
> that are very easy to fix if the right person sees them. Please take a
> look through the list to see if any of them are familiar to you.
> 
> (If you're wondering why I made this search... I've found that many
> crash reports lack enough data to be actionable -- especially those
> involving crashes caused by bad memory accesses. So it's worth
> focusing to some degree on the crash reports that are more likely to
> be actionable, and places where we deliberately abort are an obvious
> case.)
> 
> Nick
> 
> 
> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>129715  9.92 %
> 2  MOZ_CRASH() 25987   1.99 %
> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
> 21040.16 %
> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %
> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06 %
> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
>0.04 %
> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02 %
> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
>222 0.02 %
> 12 MOZ_CRASH(GFX_CRASH)215 0.02 %
> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread())   131 0.01 %
> 14 MOZ_RELEASE_ASSERT(aMsg.priority() ==
> IPC::Message::PRIORITY_NORMAL)120 0.01 %
> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
> refcount)   113 0.01 %
> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
> requests) 110 0.01 %
> 17 MOZ_RELEASE_ASSERT(ok)  105 0.01 %
> 18 MOZ_CRASH(GFX: D3D11 timeout)   99  0.01 %
> 19 MOZ_CRASH(invalid process aSelector)73  0.01 %
> 20 MOZ_CRASH(We lost the following char message)   58  0.00 %
> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.)
>53  0.00 %
> 22 MOZ_CRASH(TODO: sourcebuffer was deleted from under us) 52
>0.00 %
> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL ||
> NS_IsMainThread())  51  0.00 %
> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device
> reset)   45  0.00 %
> 25 MOZ_RELEASE_ASSERT(isSystem)42  0.00 %
> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41  0.00 %
> 27 MOZ_CRASH(sandbox_init() failed)41  0.00 %
> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor)  37  0.00 %
> 29 MOZ_CRASH(GFX: Invalid D3D11 content device)33  0.00 %
> 30 MOZ_CRASH(Initial length is too large)  30  0.00 %
> 31 MOZ_CRASH(Could not start cubeb stream for MSG.)27  0.00 %
> 32 MOZ_CRASH(IPC message size is too large)25  0.00 %
> 33 MOZ_RELEASE_ASSERT(mWorkerLoopID == MessageLoop::current()->id())
> (not on worker thread!)  

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Josh Matthews]

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 calls the
observer service off-main-thread. If someone has contacts there, I guess
we could tell them not to do that? :-\

~ Gijs


FTR, I filed bug 1276921 for this (it won't show up in the reports since 
that component doesn't have a crash signature field).

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Gijs Kruitbosch]

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 someone has contacts there, I guess 
we could tell them not to do that? :-\


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Gabriele Svelto]

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 would be wise so the problem
> doesn't get worse? Or is it not worth even that?

What about adding file/line number information? This way one could
always tell where it's coming from even if it doesn't have a descriptive
string.

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Gijs Kruitbosch]

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 separately.


MOZ_CRASH()'s explanation string parameter is optional. Should it be
required? There are 998 calls in mozilla-central to MOZ_CRASH() without an
argument, so annotating all of these won't happen overnight.


Doesn't seem worthwhile. Annotating the one in NS_ABORT_OOM() will
cover the vast majority of the cases, and annotating (or fixing) a
handful more cases will get us almost all of the others.


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 would be wise so the problem 
doesn't get worse? Or is it not worth even that?


~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

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 string parameter is optional. Should it be
> required? There are 998 calls in mozilla-central to MOZ_CRASH() without an
> argument, so annotating all of these won't happen overnight.

Doesn't seem worthwhile. Annotating the one in NS_ABORT_OOM() will
cover the vast majority of the cases, and annotating (or fixing) a
handful more cases will get us almost all of the others.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Chris Peterson]

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 optional. Should it be 
required? There are 998 calls in mozilla-central to MOZ_CRASH() without 
an argument, so annotating all of these won't happen overnight.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform