Firefox/Xulrunner memory related crashes

Marco Pesenti Gritti mpgritti at gmail.com
Fri Oct 24 12:20:06 EDT 2008


Hello,

I spent some time looking into the various tickets about oom and
BadAlloc crashes in trac today. Here is a summary of the problems.

A) There is a bug in cairo which causes BadAlloc on very big images.
Fixes are in 1.8 and should be possible to backport to 1.6.4.

B) Xulrunner renders images in a cache, normally on the server side,
but there is an environment variable to cache them on the client side,
for 15 seconds. In the case of pages like
http://wiki.laptop.org/go/Measure, the uncompressed images can take up
to 150mb, which quickly kill the XO. There are two possibilities to
alleviate the problem:

1) Reduce the cache life, most likely based on images size. Very easy
to patch xulrunner to change the timer, but it's probably not going to
completely fix the problem. Memory will fill up anyway in some cases,
we just decrease the likeliness that it will happen.

http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/imgContainer.cpp#1209

2) nsThebesImage has recently gained low memory detection. It will
refuse to create the image if memory is low. Unfortunately it's
implemented only on some platforms, not including linux. Can a kernel
hacker land me hand there and suggest an implementation for it?
NS_OSSO (meamo) uses /sys/kernel/high_watermark, but I suspect that's
a maemo kernel patch?

http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsMemoryImpl.cpp#187

---

Fixing any of these problems would require system changes and hence 8.2.1.

A) will get fixed for free when we upgrade to Fedora 10. For B), if I
get some help by kernel developers, I'd like to get a fix in joyride
and see how much it helps, then we can decide about including it in
8.2.1 or not.

>From a user point of view I think B is happening much more often then
A, hence I think it's worth to get do a 8.2.1 for this only if we
manage to solve B.

Marco



More information about the Devel mailing list