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

Randomly crashed today https://crash-stats.mozilla.com/report/index/50914f5a-d272-4bc0-8f6b-26ef82151212

One more https://crash-stats.mozilla.com/report/index/8a8f8d41-73f5-43fc-ac72-70c322151214

¡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

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.

#7 topcrash right now on release and still high volume in beta. But too late to fix for 43.

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.

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.

These look like OOM crashes inside jemalloc. Perhaps these could be hooked into the OOM crash reporting.

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?

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.

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

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.

It is possible to make pages_commit fallible in mozjemalloc, as per comment 9.

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.

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/

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've had 3 bp-d82ee57c-4c58-4b83-9e9f-e80302160312 (~500 tabs) bp-dce13b8a-9f63-487d-81a1-9dab12160229 bp-416da98a-edea-4623-b9de-72c232160312 (back in jan or feb)

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.

Currently not showing up in the 47.0b3 top 50 list.

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

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

It's possible some of these moved to bug 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

¡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

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

Too late for firefox 52, mass-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

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.

(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

The signature for this changed in 57 to [@ 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.

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

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

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.

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.

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 '+'.

(In reply to Nicholas Nethercote [:njn] from comment #51) > Spaces around '+'. I'll leave it as-is, because it's fixed in bug 1412221.

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

https://hg.mozilla.org/mozilla-central/rev/ebf19b9491fe https://hg.mozilla.org/mozilla-central/rev/470e491047b7 https://hg.mozilla.org/mozilla-central/rev/fa4a07b91fc2 https://hg.mozilla.org/mozilla-central/rev/83980ff3d5e5

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?

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.