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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
