Crash reports now include several hints about whether they are OOM crashes: * For infallible allocations, the OOMAllocationSize annotation is set. If the failed allocation size is less than 300MB (?), we should consider it a true OOM crash. * For fallible allocations, we can still guess using the "Available Virtual Memory" field (only on Win32). If the available virtual memory is less than 300MB (?), the crash is likely due to OOM. I'd like to know what percent of crashes fall into each category, and whether there are any correlations between OOMing and having certain add-ons installed. (The individual signatures might not have enough data for correlations?) See also bug 725024. I'm not sure whether to give this to Socorro team or Metrics team.

For infallible allocations I'd actually like to spend some time breaking things down. There are really two classes of possible issues: 1) variable-size allocations controlled by content which should be fallible. I can classify by caller and whether the allocation size is variable. 2) fixed-size allocations which are failing regularly. Especially if we appear to have enough VM and address space this may indicate a bug in the allocator itself or some other strange condition. I have access to do queries on the production data but I haven't spent time investigating the available query languages yet.

It looks like FireFox 25 has this issue, too: http://crash-stats.mozilla.com/report/index/e738fe2e-727b-4976-a33e-b91402131115 Signature: mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | xul.dll@0x2899da | xul.dll@0x289959 | xul.dll@0x257a84 | xul.dll@0x1c5d21 | xul.dll@0x21371a | xul.dll@0x63fb | xul.dll@0x1999a5 | xul.dll@0x1a2ee1 | xul.dll@0x22bfd4... Can we somehow make FF stop crashing during memory allocation procedures? What is wrong with the current memory management if it can not survive this?

> Signature: mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned > int) | moz_xmalloc | xul.dll@0x2899da | xul.dll@0x289959 | xul.dll@0x257a84 > | xul.dll@0x1c5d21 | xul.dll@0x21371a | xul.dll@0x63fb | xul.dll@0x1999a5 | > xul.dll@0x1a2ee1 | xul.dll@0x22bfd4... > > Can we somehow make FF stop crashing during memory allocation procedures? > What is wrong with the current memory management if it can not survive this? That crash report indicates that Firefox crashed because it ran of out memory. This bug report is about analyzing crash stats to see if there are any interesting patterns. If you are seeing frequent crashes of this type yourself, please file a new bug report about it. Thanks!

I am confused about running out of memory. All of opened applications and the OS only took 41% of memory, with 9.5 GB left free (of 16 GB total). So it should not be memory issue. (And even if the memory was running out indeed, FF engine has to display proper message about it, not crash.) I will look if there will be similar crashes (my guess is most often those crashes do not produce dump files, so no signatures) and will file a report, if it will continue. Thanks for advice, Nicholas.

Firefox on Windows is built as a 32-bit binary, so it can only use 4GB of memory. We divide memory allocations into fallible (which we handle failure for) and infallible (which we abort the app on). In general handling OOM conditions without introducing security bugs is a very difficult problem, so we default to infallible allocation.

can be done now with api, super search, or data platform