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": "0xf0000" - which is 983040 bytes, less than 1MB. --BDS On Tue, May 31, 2016 at 12:37 PM, Jonathan Kew <jfkth...@gmail.com> wrote: > On May 31, 2016, at 2:22 , Nicholas Nethercote >>>> <n.netherc...@gmail.com> 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 Memory 2147352576 > > Available Virtual Memory 122331136 > > System Memory Use Percentage 52 > > 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 still....why 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
