The number of crashes and assertions related to OOM conditions keeps growing (every larger new piece of code introduces additional OOM failures). Today, I count at least a dozen signatures related to OOM (probably more), that I see daily in the fuzzer. While I understand that fixing these bugs is not priority, the reality is that they don't get fixed at all. This is dangerous because some of these bugs have somewhat generic signatures and other bugs with the same signatures might go unseen because of that. With the testing function added in bug 872823, the fuzzer can easily create short test cases for some of these OOM bugs. However, these tests are usually short-lived and a developer needs to start working on it right after it was filed, not a month or two later (when it's guaranteed to not reproduce and also impossible to tell if it's fixed or not). I'd like to discuss ways to achieve this. Even a commitment to fixing only *one* OOM bug per week would quickly drive down the number of bugs. Even one per month would improve the situation.

Like you said, it's not a high priority for us and most of these bugs are not dangerous, but I agree there are probably some serious issues. It's a bit like the differential testing bugs Gary is filing. We have to fix many old bugs first; that will take a while and many of them are edge cases, but after that we will hopefully be able to catch new and more interesting bugs much sooner. It would be nice if somebody could step up and triage/fix a few of these OOM bugs every week. I'd be happy to do it, but getting the differential testing bugs fixed already takes a lot of time. Anybody else maybe?

Naveed, Hannes suggests that I file 1-2 OOM bugs (starting with the most common), and get you to assign an owner for them. Once they are solved, I can file a new one. Due to the nature of OOM bugs, it is often not possible to bisect them at all. The initial owner could be any JS dev who then either fixes the problem directly, or assigns it to the person working in the area where the OOM is likely happening and not being handled properly.

I'm opposed to asking decoder to throttle these bugs on principle. We're talking about a quality problem, possibly a security problem. Decoder offered this search as a starting point for OOM bugs: http://tinyurl.com/k8uscwm I see 15 open bugs, including some old ones that might be gone.

(In reply to Jason Orendorff [:jorendorff] from comment #3) > I'm opposed to asking decoder to throttle these bugs on principle. We're > talking about a quality problem, possibly a security problem. I used to throttle my Differential Testing bugs too until jandem picked them up recently and consistently kept fixing them (or assigned people to fix them), since he could do the initial triage and/or analysis and assign the right person. Otherwise it's just too much to handle for a non-JS tech person, we need a point person for OOM bugs. Not really to fix everything, but to handle the initial triage/analysis in a role similar to jandem.

If Christian and Gary can order these by importance (e.g. likelyhood of masking more important signatures), then I think this should actually be quite a useful activity. I would be happy do triage, although I may have to rate-limit it to a handful a week.

Judging by the ones that *have* been fixed, about half seem to be due to failure to check for NULL return values. You may be able to identify these easily: * the symptom is either "Assertion failure: foo != NULL" or "Assertion failure: foo" or some similar assertion, or a crash near NULL * they reproduce reliably -- might even bisect, if you can do that for OOMAfter bugs. And they're easy to fix. So these should be filed as regressions, and if you find one that's a recent regression, I think we should back out the original patch if the committer isn't around or doesn't have time to fix it at the moment. The other half don't seem to have a single common source.

Jason and Terrence thanks for taking on this triage