Cairo graphics reports “out of memory” error condition when the author didn’t have time to figure out what went wrong. We caught a few problems that were being reported as out of memory (we would pick up the Cairo library error as out of memory, and dutifully propagate it up the chain), when they weren’t and could be properly handled.
We will also report out of memory when we mean out of resources. If Direct3D library can’t give us what we’re asking for, they will give us the out of memory error code, but that doesn’t mean that we are out of memory as such. We could be out of file descriptors or some other resource (or contiguous memory on the graphics card.) We can’t really easily tell these apart, so the best we can report is OOM. I don’t know if there are any other places in our code where this kind of thing happens, and I don’t know if we care about the second one, but wanted to point out that showing a lot of available “regular” memory would be something that would happen in both of the cases I mentioned above. — - Milan > On May 31, 2016, at 19:51 , Nicholas Nethercote <n.netherc...@gmail.com> > wrote: > > On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew <jfkth...@gmail.com> wrote: >> >> 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?! > > I looked at a bunch of these yesterday. It's pretty common for OOM to > occur when there is around 200--250 MiB of available virtual memory; > 122 MB is probably lower than normal. As bsmedberg said, jemalloc uses > 1 MiB chunks so the size of 24 is something of a red herring here. > (It's still useful in the sense that it's tiny, so making this > allocation fallible is unlikely to be helpful.) > > More generally, I did a search yesterday of all our "OOM | small" > crashes for the past week. About 5% of them occur when the user has > > 1 GiB of available virtual memory *and* > 1 GiB of available physical > memory, which is surprising. I would love to see a scatter plot > showing available physical memory vs. available virtual memory for all > our "OOM | small" crashes. bsmedberg, do we have tools to extract that > kind of data from crash-stats? > > Nick > _______________________________________________ > 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
