In stability-land we're starting to see some "interesting" problems relating to virtual memory usage in Firefox on Windows.

See bug 875030 for information that led me along this path. In this case, the user has plenty of memory (according to Windows) and is still failing to allocate moderate-size graphics buffers (1-2MB). This has very similar symptoms to a bunch of other crashes that we've been seeing in low volume over the past few years. This has become more urgent because low-memory crashes often fail to report good crash reports (because taking a crash reporting minidump requires some allocation on Windows).

Fortunately on Windows, the minidump contains complete information about the access and commit state of every process page. I have created a visualizer for this information here: http://people.mozilla.com/~bsmedberg/graphical-minidump-memoryinfo/

In this case, the crash report shows "Available Virtual Memory" as 303558656, but in fact the largest contiguous block of available VM is 64k.

There are a couple problems here:

1) early in the memory info, there appears to be a common pattern of a committed block and then 15 free blocks. 2) later on, there appear to be a large number of 8.7MB allocated blocks which are mapped memory. The minidump does not appear tell me any more about the mapping, whether it is a file mapping, or named or anonymous shared memory. 3) The user (who can reproduce this reliably) reports that disabling the nviia graphics card and switching to integrated graphics on their laptop solves the issue.

I think we need to urgently solve the most common crash issue by making more graphics allocations fallible (bug 829954), and I think Bas is working on that. But that's only going to cause Firefox behave weirdly instead of crashing.

Either our code or the ATI driver is leaking mapped memory references in a way that chews up VM space without actually using memory. We need to figure out why and fix our work around the problem. I'm hoping that one of you on the "To" of this email may be able to help figure out a way to either patch Firefox or run an external debugging tool which can help record information about the stacks when these mappings are typically created and destroyed, and help create a detailed understanding of the problem so that we can either fix our code or hand the problem to the nvidia developers with the most reproducible/detailed report possible.

--BDS

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to