This bug is for crash report bp-bc1a8b90-a3c2-4d30-ae7a-dbf6e0200219.

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:54
3 xul.dll mozilla::BufferList<InfallibleAllocPolicy>::WriteBytes mfbt/BufferList.h:412
4 xul.dll IPC::Channel::ChannelImpl::ProcessIncomingMessages ipc/chromium/src/chrome/common/ipc_channel_win.cc:395
5 xul.dll base::MessagePumpForIO::WaitForIOCompletion ipc/chromium/src/base/message_pump_win.cc:471
6 xul.dll base::MessagePumpForIO::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:424
7 xul.dll base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:79
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290

ID: bc1a8b90-a3c2-4d30-ae7a-dbf6e0200219

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0 ID:20200218224219

Do you have reliable steps to reproduce this? Is your system under heavy load when this happens (as it's an OOM crash, ie we failed to allocate memory) ?

(In reply to :Gijs (he/him) from comment #2)

Do you have reliable steps to reproduce this? Is your system under heavy load when this happens (as it's an OOM crash, ie we failed to allocate memory) ?

1. No.
2. Most likely. Still, it shouldn't just dump you out (crash). It should give a message and then do something (wait, opt to close, warn, something).

(In reply to Worcester12345 from comment #3)

Still, it shouldn't just dump you out (crash). It should give a message and then do something (wait, opt to close, warn, something).

This isn't really possible if memory allocations are failing, we'd try and create a dialog and the OS basically says "no" to our request to create anything.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Lots of these reports appear to have reasonable amounts of memory available per the crash reports:
https://crash-stats.mozilla.org/signature/?product=Firefox&proto_signature=~ProcessIncomingMess&signature=OOM%20%7C%20small&date=%3E%3D2020-03-04T17%3A54%3A00.000Z&date=%3C2020-03-11T17%3A54%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

The ones I looked at in there were typically 4k allocations, and the browser had 200MB or more available (sometimes much more), though I didn't look at too many of them. So, why the OOM in this case? They weren't Linux (overcommit...)

Glandium, any thoughts on this subset of OOM crashes?

Hard to tell without more data about the allocator state. The many of the few I looked at have a very low available page file size.

The priority flag is not set for this bug.
:jld, could you have a look please?

For more information, please visit auto_nag documentation.

OOM | small generally isn't actionable, and this bug in particular doesn't appear to have anything more to go on.

FWIW, the OOMs I've looked at recently had very low pagefile available, even if they had lots of memory free. I'm not sure what that means.

This isn't an IPC bug, but I think it is okay to close it without more specific information.

FWIW, the OOMs I've looked at recently had very low pagefile available, even if they had lots of memory free. I'm not sure what that means.

Windows for example requires swap space for backing shared memory, so this could very well be related.