Closed Bug 1229384 Opened 9 years ago Closed 7 years ago

Out of memory crash in moz_abort | pages_commit

Categories

(Core :: Memory Allocator, defect)

Product:
Core
Component:
Memory Allocator
Platform:
All
Windows
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla58
Tracking Flags:
Tracking Status
firefox42 --- wontfix
firefox43 + wontfix
firefox44 + wontfix
firefox45 - wontfix
firefox46 - wontfix
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: lizzard, Assigned: glandium)

References

Details

(Keywords: crash, nightly-community, topcrash, Whiteboard: [gfx-noted])

Crash Data

Attachments

(4 files)

Bug 1229384 - Reformat and apply Gecko style to a few functions.
59 bytes, text/x-review-board-request
n.nethercote
: review+
Details
Bug 1229384 - Invert the meaning of the arena_ralloc_large and arena_t::RallocGrowLarge return type.
59 bytes, text/x-review-board-request
n.nethercote
: review+
Details
Bug 1229384 - In SplitRun, adjust the set of available runs after committing pages.
59 bytes, text/x-review-board-request
n.nethercote
: review+
Details
Bug 1229384 - Make pages_commit fallible.
59 bytes, text/x-review-board-request
n.nethercote
: review+
Details 
This bug was filed from the Socorro interface and is 
report bp-1975793b-2f32-403f-b7e5-a7b212151128.
=============================================================

This is currently a topcrash in beta 43, with 581 crashes in 43.0b7 in the last few days. 

Crashing thread:

0 	mozglue.dll 	moz_abort 	memory/build/jemalloc_config.cpp
1 	mozglue.dll 	pages_commit 	memory/mozjemalloc/jemalloc.c
2 	mozglue.dll 	arena_run_split 	memory/mozjemalloc/jemalloc.c
3 	mozglue.dll 	arena_malloc_large 	memory/mozjemalloc/jemalloc.c
4 	mozglue.dll 	je_malloc 	memory/mozjemalloc/jemalloc.c
5 	xul.dll 	gfxImageSurface::AllocateAndInit(long, int, bool) 	gfx/thebes/gfxImageSurface.cpp
6 	xul.dll 	gfxImageSurface::gfxImageSurface(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, gfxImageFormat, bool) 	gfx/thebes/gfxImageSurface.cpp
7 	xul.dll 	gfxWindowsPlatform::CreateOffscreenSurface(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, gfxImageFormat) 	gfx/thebes/gfxWindowsPlatform.cpp
8 	xul.dll 	gfxPlatform::CreateDrawTargetForBackend(mozilla::gfx::BackendType, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SurfaceFormat) 	gfx/thebes/gfxPlatform.cpp
9 	xul.dll 	mozilla::layers::PersistentBufferProviderBasic::PersistentBufferProviderBasic(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::SurfaceFormat, mozilla::gfx::BackendType) 	gfx/layers/PersistentBufferProvider.cpp
10 	xul.dll 	mozilla::layers::LayerManager::CreatePersistentBufferProvider(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SurfaceFormat) 	gfx/layers/Layers.cpp
11 	xul.dll 	mozilla::dom::CanvasRenderingContext2D::EnsureTarget(mozilla::dom::CanvasRenderingContext2D::RenderingMode) 	dom/canvas/CanvasRenderingContext2D.cpp
12 	xul.dll 	mozilla::dom::CanvasRenderingContext2D::Save() 	dom/canvas/CanvasRenderingContext2D.cpp
13 	xul.dll 	mozilla::dom::CanvasRenderingContext2DBinding::save 	obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp
¡Hola Liz!

Just crashed like this on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20151215030221 CSet: ae37fdb042c07c0cb9d0afcd41372a96454f4f4f :

Report ID 	Date Submitted
bp-88097bcf-4adb-4e6b-96f7-b7c002151215
	12/15/2015	4:06 PM

This happened right after a Windows 7 warning about low memory on the computer.

Might be an OOM crash in disguise?

¡Gracias!

This still heavy volume crash with ~11000 crashes in the past week per https://crash-stats.mozilla.com/report/list?product=Firefox&signature=moz_abort+%7C+pages_commit

Crashing Thread
Frame	Module	Signature	Source
0	mozglue.dll	moz_abort	memory/build/jemalloc_config.cpp
1	mozglue.dll	pages_commit	memory/mozjemalloc/jemalloc.c
2	mozglue.dll	arena_run_split	memory/mozjemalloc/jemalloc.c
3	mozglue.dll	arena_malloc_large	memory/mozjemalloc/jemalloc.c
4	mozglue.dll	malloc_impl	memory/build/replace_malloc.c
5	xul.dll	js::LifoAlloc::getOrCreateChunk(unsigned int)	js/src/ds/LifoAlloc.cpp
6	xul.dll	js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*)	js/src/vm/TypeInference.cpp
7	xul.dll	SweepArenaList<js::ObjectGroup, js::AutoClearTypeInferenceStateOnOOM*>	js/src/jsgc.cpp
8	xul.dll	js::gc::GCRuntime::sweepPhase(js::SliceBudget&)	js/src/jsgc.cpp
9	xul.dll	js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason)	js/src/jsgc.cpp
10	xul.dll	js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason)	js/src/jsgc.cpp
11	xul.dll	js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason)	js/src/jsgc.cpp
12	xul.dll	js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason)	js/src/jsgc.cpp
13	xul.dll	nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, __int64)	dom/base/nsJSEnvironment.cpp
14	xul.dll	nsJSEnvironmentObserver::Observe(nsISupports*, char const*, wchar_t const*)	dom/base/nsJSEnvironment.cpp
15	xul.dll	nsObserverList::NotifyObservers(nsISupports*, char const*, wchar_t const*)	xpcom/ds/nsObserverList.cpp
16	xul.dll	nsObserverService::NotifyObservers(nsISupports*, char const*, wchar_t const*)	xpcom/ds/nsObserverService.cpp
17	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp
18	xul.dll	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)	ipc/glue/MessagePump.cpp
19	xul.dll	MessageLoop::RunHandler()	ipc/chromium/src/base/message_loop.cc
20	xul.dll	MessageLoop::Run()	ipc/chromium/src/base/message_loop.cc
21	xul.dll	nsBaseAppShell::Run()	widget/nsBaseAppShell.cpp
22	xul.dll	nsAppShell::Run()	widget/windows/nsAppShell.cpp
23	xul.dll	nsAppStartup::Run()	toolkit/components/startup/nsAppStartup.cpp
24	xul.dll	XREMain::XRE_mainRun()	toolkit/xre/nsAppRunner.cpp
25	xul.dll	XREMain::XRE_main(int, char** const, nsXREAppData const*)	toolkit/xre/nsAppRunner.cpp
26	xul.dll	XRE_main	toolkit/xre/nsAppRunner.cpp
27	firefox.exe	do_main	browser/app/nsBrowserApp.cpp
28	firefox.exe	NS_internal_main(int, char**)	browser/app/nsBrowserApp.cpp
29	firefox.exe	wmain	toolkit/xre/nsWindowsWMain.cpp
30	firefox.exe	__tmainCRTStartup	f:/dd/vctools/crt/crtw32/startup/crt0.c:255
31	kernel32.dll	BaseThreadInitThunk	
32	ntdll.dll	__RtlUserThreadStart	
33	ntdll.dll	_RtlUserThreadStart
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: --- → affected
Flags: needinfo?(lhenry)
Version: unspecified → Trunk
Anecdotal evidence of memory usage:
* 100% occur with <50% memory remaining
*  88% occur with <30% memory remaining
*  68% occur with <20% memory remaining
*  34% occur with <10% memory remaining

I'd say it's very likely that OOM is a factor here, at least in some instances.
Whiteboard: [gfx-noted]
#7 topcrash right now on release and still high volume in beta. But too late to fix for 43.
status-firefox43: affected → wontfix
tracking-firefox44: --- → ?
tracking-firefox45: --- → ?
tracking-firefox46: --- → +
Flags: needinfo?(lhenry)
Wontfix for 44 as well. 
This is still a high volume crash on 43.0.4 and 44. It's the #9 topcrash on nightly. I'll try emailing crash-debug to see if someone can investigate.
status-firefox44: affected → wontfix
tracking-firefox44: ? → +
tracking-firefox45: ? → +
Keywords: topcrash
This is only randomly sitting in graphics, the signature seems to be catching all sorts of OOM conditions, right?  For example, out of the latest few in 46,  these seems to be JS:

https://crash-stats.mozilla.com/report/index/74a058cb-6793-4bb5-8e22-7a92e2160109
https://crash-stats.mozilla.com/report/index/146af7f4-ade9-4bbd-8aa3-12ad42160111
https://crash-stats.mozilla.com/report/index/93506df8-3a74-4db9-bb2d-453102160114
https://crash-stats.mozilla.com/report/index/473e44a4-be0a-4919-b095-b9cb72160110
https://crash-stats.mozilla.com/report/index/c6a13ae7-780c-4b73-8a59-4e3ac2160113

no idea what this is:
https://crash-stats.mozilla.com/report/index/bfa794be-96bb-4a52-9b5e-a45a42160109

and then this one in graphics:
https://crash-stats.mozilla.com/report/index/1273e521-c4f6-413f-88c6-4d34c2160112

If we want to make something out of this, we need to do something about the signatures, and not go off the moz_abort | pages_commit, but ignore the stack until the caller to malloc_impl.
Component: Graphics: Layers → General
Blocks: 1242925
These look like OOM crashes inside jemalloc. Perhaps these could be hooked into the OOM crash reporting.
Component: General → Memory Allocator
Copy/Paste from a mail thread that was likely about this bug:

On Wed, Jan 13, 2016 at 03:58:31PM -0700, Aaron Klotz wrote:
> +glandium to hear his $0.02
> 
> On 1/13/2016 3:55 PM, Kyle Huey wrote:
> >At least in this case, we have the size right there.  We're just calling
> >C's abort()
> >
> >http://hg.mozilla.org/mozilla-central/annotate/ae37fdb042c0/memory/mozjemalloc/jemalloc.c#l2068

In this case we *don't* have the size. What we have there is the size of
the address space that is being tried to be committed, which may or may
not match the malloc size. And since the specific crash trace goes
through arena_run_split, we're in a case where it doesn't match.

It's one of those tricky cases where we have mapped more memory than the
OS can give us, and subsequently fail to commit that memory. The
allocation that triggered that may or may not even be directly involved.

The proper thing to do here is to fix jemalloc to "gracefully" return a
failed allocation instead of abort()ing. Jemalloc4 does that properly, btw.

Mike
If we do that, then the normal mozalloc OOM machinery should apply, and these crashes would get bucketed properly as OOM crashes?
Summary: crash in moz_abort | pages_commit → Out of memory crash in moz_abort | pages_commit
Got this today at page load, https://crash-stats.mozilla.com/report/index/bff7634b-b4d3-4ac2-96da-8f8bc2160212, not deterministically reproducible.
Benjamin commented that upgrading to jemalloc 4 would help make this a fallible crash. 
glandium or njn, can you help here? Thanks.
Flags: needinfo?(n.nethercote)
Flags: needinfo?(mh+mozilla)
> Benjamin commented that upgrading to jemalloc 4 would help make this a
> fallible crash. 
> glandium or njn, can you help here? Thanks.

glandium has spent a heroic amount of effort over the past year trying to upgrade to jemalloc 4. Unfortunately there are still performance regressions that are preventing it from riding the trains.
Flags: needinfo?(n.nethercote)
OK! Thanks for the info and the heroic efforts. I see that work now hanging off bug 762449 and bug 1201802. 
Since this crash report isn't currently actionable, I'm going to untrack the bug.
tracking-firefox45: + → -
tracking-firefox46: + → -
It is possible to make pages_commit fallible in mozjemalloc, as per comment 9.
Flags: needinfo?(mh+mozilla)
also comments in the crash reports seem to indicate that memory use seems to be wildly out of control.  With some analysis of the URLs we might also understand where we might have some recent leaks that contribute to getting to the condition where we have allocation mismatches.  That would be another thing to investigate on this bug.
Some work on memory usage is going on in bug 1249739, for example - and AFAIK, MemShrink is still an ongoing initiative.
(In reply to chris hofmann from comment #16)
> With some analysis of the URLs we might also
> understand where we might have some recent leaks that contribute to getting
> to the condition where we have allocation mismatches.  That would be another
> thing to investigate on this bug.

Yes, having a list of URLs associated with this crash could be useful. Note, though, that out of control memory usage is not necessarily a Firefox bug. But if we have a webpage that uses a ton of memory in Firefox, it is easy enough to compare to memory usage in say Chrome to get a rough sense if the page is at fault or not.
Keywords: needURLs
That's the top URLs for this signature, it's pretty much the usual suspects, and Facebook to a very high degree.

1575 	https://www.facebook.com/
206 	about:newtab
129 	about:sessionrestore
125 	about:blank
121 	https://mail.google.com/mail/u/0/#inbox
103 	about:home
99 	https://www.youtube.com/
57 	https://www.facebook.com/?ref=tn_tnmn
50 	http://ok.ru/
41 	https://web.whatsapp.com/
27 	https://mail.google.com/mail/u/0/?tab=wm#inbox
25 	https://twitter.com/
24 	https://www.yahoo.com/
21 	http://www.netflix.com/browse
21 	https://www.yandex.ru/
Keywords: needURLs
so one test case that's worth constructing and checking is some general facebook usage on this matrix.

do we have some test case that mimic some common user behavior on facebook?


   browser to check                             memory consumed
firefox 42 (pre spike in this signature)  -  
firefox 43 (first notice of the spike)    -
firefox 44 (what we are shipping now)     -
firefox 45b9 (what's planned to go out next) -

chrome latest                               -
I see this as one of the crashes. I don't have a STR yet. However, here the condition under which I get this crash:

On Win10 64-bit + Nightly 32-bit e10s DISABLED, when I view a Flash Video with VLC, with Firefox in the background, the firefox.exe size in task manager starts ballooning and I sometimes get an OOM and firefox crashes. This is repeatable but the crashes are not the same. Some of the crashes are:
https://crash-stats.mozilla.com/report/index/bp-ecf85e54-a5b0-4ae1-ba0b-e0baf2160318
https://crash-stats.mozilla.com/report/index/bp-ecd37cb0-3cd9-497b-bd1d-309f42160319 
3e5803d3-978f-47e7-a33f-5d11fa521176 (not submitted to crash-stats?)
https://crash-stats.mozilla.com/report/index/bp-eb34b0c4-61ff-4948-b487-3d33a2160319

On Win10 64-bit + Nightly 32-bit e10s ENABLED, when I view a Flash Video with VLC, with Firefox in the background, the plugin_container.exe size in task manager starts ballooning and I sometimes get an OOM and the PC crashes.
Blocks: e10s-oom
Currently not showing up in the 47.0b3 top 50 list.
No longer blocks: e10s-oom
Crash volume for signature 'moz_abort | pages_commit':
 - nightly (version 50): 83 crashes from 2016-06-06.
 - aurora  (version 49): 147 crashes from 2016-06-07.
 - beta    (version 48): 1709 crashes from 2016-06-06.
 - release (version 47): 8648 crashes from 2016-05-31.
 - esr     (version 45): 4301 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly         15          9         10         10          9          8         16
 - aurora          23         33         18         20         22         23          4
 - beta           265        273        252        272        263        225         77
 - release       1403       1405       1261       1260       1296       1220        421
 - esr            563        569        453        469        539        460        295

Affected platform: Windows
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox-esr45: --- → affected
Crash volume for signature 'moz_abort | pages_commit':
 - nightly (version 51): 41 crashes from 2016-08-01.
 - aurora  (version 50): 69 crashes from 2016-08-01.
 - beta    (version 49): 739 crashes from 2016-08-02.
 - release (version 48): 1158 crashes from 2016-07-25.
 - esr     (version 45): 5926 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly      14      13       8
 - aurora       21      37       4
 - beta        247     242      88
 - release     363     363     170
 - esr         489     449     478

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #91       #85
 - aurora  #73       #103
 - beta    #58       #60       #1236
 - release #47       #66
 - esr     #10
status-firefox51: --- → affected
It's possible some of these moved to bug 1298836.
See Also: → 1298836
Crash volume for signature 'moz_abort | pages_commit':
 - nightly (version 52): 11 crashes from 2016-09-19.
 - aurora  (version 51): 31 crashes from 2016-09-19.
 - beta    (version 50): 236 crashes from 2016-09-20.
 - release (version 49): 1511 crashes from 2016-09-05.
 - esr     (version 45): 8379 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       5       6
 - aurora       28       3
 - beta        200      36
 - release    1175     335
 - esr         611     665

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #458      #201
 - aurora  #60       #97
 - beta    #78       #139
 - release #45       #47       #3015
 - esr     #10
status-firefox52: --- → affected
¡Hola Liz!

FWIW This one jumped up 8 spots to top 44 crash in Nightly.

¡Gracias!
Alex

https://crash-stats.mozilla.com/report/index/31568b6d-1518-4896-a590-478d82161214

Crashing Thread (70)
Frame 	Module 	Signature 	Source
0 	mozglue.dll 	moz_abort 	memory/build/jemalloc_config.cpp:163
1 	mozglue.dll 	pages_commit 	memory/mozjemalloc/jemalloc.c:2079
2 	mozglue.dll 	chunk_recycle 	memory/mozjemalloc/jemalloc.c:2899
3 	mozglue.dll 	chunk_alloc 	memory/mozjemalloc/jemalloc.c:2940
4 	mozglue.dll 	arena_malloc_large 	memory/mozjemalloc/jemalloc.c:4279
5 	mozglue.dll 	malloc_impl 	memory/build/replace_malloc.c:151
6 	xul.dll 	PLDHashTable::Add(void const*, mozilla::fallible_t const&) 	xpcom/glue/PLDHashTable.cpp:540
7 	xul.dll 	CCGraphBuilder::AddNode(void*, nsCycleCollectionParticipant*) 	xpcom/base/nsCycleCollector.cpp:2214
8 	xul.dll 	CCGraphBuilder::NoteRoot(void*, nsCycleCollectionParticipant*) 	xpcom/base/nsCycleCollector.cpp:2143
9 	xul.dll 	mozilla::CycleCollectedJSContext::TraverseNativeRoots(nsCycleCollectionNoteRootCallback&) 	xpcom/base/CycleCollectedJSContext.cpp:779
10 	xul.dll 	mozilla::CycleCollectedJSContext::TraverseRoots(nsCycleCollectionNoteRootCallback&) 	xpcom/base/CycleCollectedJSContext.cpp:1213
11 	xul.dll 	nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) 	xpcom/base/nsCycleCollector.cpp:3853
12 	xul.dll 	nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*, bool) 	xpcom/base/nsCycleCollector.cpp:3651
13 	xul.dll 	nsCycleCollector_collect(nsICycleCollectorListener*) 	xpcom/base/nsCycleCollector.cpp:4144
14 	xul.dll 	`anonymous namespace'::WorkerJSContext::CustomGCCallback 	dom/workers/RuntimeService.cpp:1132
15 	xul.dll 	js::gc::GCRuntime::callGCCallback(JSGCStatus) 	js/src/jsgc.cpp:1362
16 	xul.dll 	`anonymous namespace'::AutoNotifyGCActivity::~AutoNotifyGCActivity 	js/src/jsgc.cpp:1393
17 	xul.dll 	js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) 	js/src/jsgc.cpp:6200
18 	xul.dll 	js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) 	js/src/jsgc.cpp:6337
19 	xul.dll 	js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason) 	js/src/jsgc.cpp:6398
20 	xul.dll 	mozilla::dom::workers::WorkerPrivate::GarbageCollectInternal(JSContext*, bool, bool) 	dom/workers/WorkerPrivate.cpp:6267
21 	xul.dll 	`anonymous namespace'::GarbageCollectRunnable::WorkerRun 	dom/workers/WorkerPrivate.cpp:1394
22 	xul.dll 	mozilla::dom::workers::WorkerRunnable::Run() 	dom/workers/WorkerRunnable.cpp:374
23 	xul.dll 	mozilla::dom::workers::WorkerPrivate::ProcessAllControlRunnablesLocked() 	dom/workers/WorkerPrivate.cpp:5055
24 	xul.dll 	mozilla::dom::workers::WorkerPrivate::DoRunLoop(JSContext*) 	dom/workers/WorkerPrivate.cpp:4576
25 	xul.dll 	`anonymous namespace'::WorkerThreadPrimaryRunnable::Run 	dom/workers/RuntimeService.cpp:2871
26 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1213
27 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp:381
28 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:368
29 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:225
30 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:205
31 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:467
32 	nss3.dll 	PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
33 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
34 	ucrtbase.dll 	o__realloc_base 	
35 	kernel32.dll 	BaseThreadInitThunk 	
36 	ntdll.dll 	RtlUserThreadStart
status-firefox53: --- → affected
Keywords: nightly-community
Crash volume for signature 'moz_abort | pages_commit':
 - nightly (version 54): 26 crashes from 2017-01-23.
 - aurora  (version 53): 6 crashes from 2017-01-23.
 - beta    (version 52): 200 crashes from 2017-01-23.
 - release (version 51): 775 crashes from 2017-01-16.
 - esr     (version 45): 19698 crashes from 2016-08-03.

Crash volume on the last weeks (Week N is from 01-30 to 02-05):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly      20
 - aurora        6
 - beta        121
 - release     391       0
 - esr         968     948     992     732     519     864     937

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #75       #34
 - aurora  #230      #56
 - beta    #53       #38
 - release #40       #30       #756
 - esr     #14       #2        #766
status-firefox54: --- → affected
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
¡Hola!

This is pestering me on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170426030329 CSet: 0f5ba06c4c5959030a05cb852656d854065e2226 today.

Updating flags per https://crash-stats.mozilla.com/signature/?product=Firefox&signature=moz_abort%20%7C%20pages_commit

It looks like a content crash now as I get the "Tab crashed" UI but eventually Nightly as a whole crumbles...

¡Gracias!
Alex

Reportes de fallos enviados
ID del reporte 	Fecha enviada
bp-f2f4db2a-318c-444c-a7a7-347d00170426
	26/04/2017	16:09
bp-477ce1b3-790e-45b2-b29c-5af270170426
	26/04/2017	16:09
bp-2614c5d6-c0cc-4a7d-ad26-e4f010170426
	26/04/2017	16:09
bp-9cff7bbb-a578-498b-b1c3-6d24c0170426
	26/04/2017	16:09
bp-4f7ad05f-369f-4668-aec8-343ce0170426
	26/04/2017	16:09
bp-19d1b690-1b75-4cab-8208-5ce3d0170426
	26/04/2017	16:09
bp-618eef61-e82d-483d-933c-2d10f0170426
	26/04/2017	16:09
bp-f63bc5bd-42b6-4f1c-902b-5cd4b0170426
	26/04/2017	16:09
bp-bb73599c-2338-4cdc-99aa-7cbd40170426
	26/04/2017	16:09
bp-206e526f-486f-4ce7-b363-d994a0170426
	26/04/2017	16:09
bp-c0b5ead2-4592-4aa9-bd35-f826b0170426
	26/04/2017	16:09
bp-2a2d472b-6579-445d-8732-1bd5a0170426
	26/04/2017	16:09
bp-00b754a7-34fa-4af1-a228-796eb0170426
	26/04/2017	16:09
bp-80e0599b-6148-4233-b0e4-e43ef0170426
	26/04/2017	16:09
bp-fb5050bb-4046-48af-9d97-87f800170426
	26/04/2017	16:09
bp-1822366d-9cd7-48a5-a096-4589a0170426
	26/04/2017	16:09
bp-65073984-8179-4ed6-b40d-b8c3b0170426
	26/04/2017	15:34
status-firefox55: --- → affected
status-firefox57: --- → affected
This is an out of memory crash. I thought you might be experiencing bug 1357872, but that should be fixed in the 4-25 Nightly. Can you please file a new bug and needinfo me? Though the crash report says your available page file is around 10MB, which sounds extremely low! Is your hard drive almost full or something? You have a ton of free memory but maybe the OS decided to page something out.
Flags: needinfo?(alex_mayorga)
(In reply to Andrew McCreight [:mccr8] from comment #32)
> This is an out of memory crash. I thought you might be experiencing bug
> 1357872, but that should be fixed in the 4-25 Nightly. Can you please file a
> new bug and needinfo me? Though the crash report says your available page
> file is around 10MB, which sounds extremely low! Is your hard drive almost
> full or something? You have a ton of free memory but maybe the OS decided to
> page something out.

¡Hola Andrew!

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1360226 as requested.

¡Gracias!
Alex
Flags: needinfo?(alex_mayorga)
See Also: → 1360226
The signature for this changed in 57 to [@ pages_commit].
Crash Signature: [@ moz_abort | pages_commit] → [@ moz_abort | pages_commit] [@ pages_commit]
This is the top crash, with about 68% of all crashes, for the 10-5 Nightly, which is an alarming increase. Nightly has about 8300 crashes, from 449 installations. So some people are hitting this quite frequently.
Sorry, I meant, 10-4 not 10-5. It is only around #7 for 10-5 so far so maybe it was just a fluke.
status-firefox54: affected → wontfix
status-firefox55: affected → wontfix
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
OS: Windows NT → Windows
Hardware: x86 → All
See Also: → 1395805
Hit this on my Win 10 Surface Pro today. I opened my machine, cnn.com tab was loaded. Browser crashed (content crash). The next thing I noticed is that I was getting Windows warnings that my machine was low on memory.
Comment on attachment 8922654 [details]
Bug 1229384 - Reformat and apply Gecko style to a few functions.

https://reviewboard.mozilla.org/r/193780/#review198996
Attachment #8922654 - Flags: review?(n.nethercote) → review+
Comment on attachment 8922655 [details]
Bug 1229384 - Invert the meaning of the arena_ralloc_large and arena_t::RallocGrowLarge return type.

https://reviewboard.mozilla.org/r/193782/#review198998
Attachment #8922655 - Flags: review?(n.nethercote) → review+
Comment on attachment 8922656 [details]
Bug 1229384 - In SplitRun, adjust the set of available runs after committing pages.

https://reviewboard.mozilla.org/r/193784/#review199200

Sorry, but I'm going to need a bit of explanation, e.g. in the log message, to understand what's being changed here.
Attachment #8922656 - Flags: review?(n.nethercote)
Comment on attachment 8922657 [details]
Bug 1229384 - Make pages_commit fallible.

https://reviewboard.mozilla.org/r/193786/#review199202

This is a good change. In fact I'm a bit surprised at the existing behaviour... uniformly returning nullptr on OOM seems much more sensible than mostly returning nullptr but occasionally aborting.
Attachment #8922657 - Flags: review?(n.nethercote) → review+
Comment on attachment 8922656 [details]
Bug 1229384 - In SplitRun, adjust the set of available runs after committing pages.

https://reviewboard.mozilla.org/r/193784/#review199256

Much clearer, thank you.

::: memory/build/mozjemalloc.cpp:2471
(Diff revision 2)
> +
> +  mRunsAvail.Remove(&chunk->map[run_ind]);
>  
> +  /* Keep track of trailing unused pages for later use. */
> +  if (rem_pages > 0) {
> +    chunk->map[run_ind+need_pages].bits = (rem_pages <<

Spaces around '+'.
Attachment #8922656 - Flags: review?(n.nethercote) → review+
(In reply to Nicholas Nethercote [:njn] from comment #51)
> Spaces around '+'.

I'll leave it as-is, because it's fixed in bug 1412221.
Assignee: nobody → mh+mozilla
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/ebf19b9491fe
Reformat and apply Gecko style to a few functions. r=njn
https://hg.mozilla.org/integration/autoland/rev/470e491047b7
Invert the meaning of the arena_ralloc_large and arena_t::RallocGrowLarge return type. r=njn
https://hg.mozilla.org/integration/autoland/rev/fa4a07b91fc2
In SplitRun, adjust the set of available runs after committing pages. r=njn
https://hg.mozilla.org/integration/autoland/rev/83980ff3d5e5
Make pages_commit fallible. r=njn
This frequency of this crash on Beta/Release is high enough to give me pause about whether or not we should consider it for uplift this late in the cycle, but on the other hand, these patches don't exactly look like the kind of small low-risk ones we'd want to be taking at this point either. What are your thoughts, Mike?
status-firefox56: affected → wontfix
status-firefox-esr52: affected → wontfix
Flags: needinfo?(mh+mozilla)
Those patches probably don't apply on beta, because of all the changes that have happened to that file in the past few weeks. So it wouldn't be a straightforward uplift. Moreover, the patch doesn't change much. Practically speaking, it will replace one kind of OOM crash with another, shifting from pages_commit-rooted crashes to more "standard" OOM crashes. Although there's a small chance that in some cases we might hit a caller that handles failure in an appropriate way, but that just delays the OOM crash to the next allocation that fails.
Flags: needinfo?(mh+mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: