Last Comment Bug 912928 - The number of crash and assertion OOM bugs is too damn high [meta]
: The number of crash and assertion OOM bugs is too damn high [meta]
Status: NEW
: meta, sec-want
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All Linux
-- major with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on: 988953 1269705 1269714 1269718 1299115 1305739 1317329 871862 877437 914598 914601 914614 915336 915497 917759 925146 929065 929221 930526 932530 937083 940025 945568 945754 947233 947958 947963 948023 948187 948188 948233 948647 950474 950658 958598 959167 959208 964803 978802 987910 987933 987935 987947 988097 990071 990096 990787 990806 991027 991036 991249 992274 992968 994159 1000145 1000182 1026465 1026476 1111201 1130672 1133630 1155618 1164532 1171909 1175755 1177122 1180064 1186982 1188296 1188301 1188347 1188390 1188878 1189343 1191756 1191758 1193039 1193043 1193102 1195452 1196027 1199175 1204721 1204725 1204847 1204849 1204866 1205603 1205639 1205708 1206539 1206677 1207413 1207569 1207574 1207863 1208994 1209001 1209026 1209497 1209585 1209943 1209945 1211009 1211913 1211939 1211949 1211956 1211962 1211964 1211977 1212094 1212258 1212278 1212279 1212296 1212298 1212343 1212389 1212390 1212469 1212927 1214175 1215058 1215363 1215600 1215678 1216157 1216261 1216599 1216607 1223021 1223023 1225078 1232676 1233115 1234280 1234387 1234402 1234410 1234411 1234414 1236473 1236476 1236525 1238555 1238575 1238577 1238582 1238610 1240502 1240503 1240521 1240527 1240546 1240736 1240803 1241731 1242279 1242812 1242835 1242840 1243374 1243397 1243410 1243787 1245520 1245862 1246607 1248101 1252329 1252707 1252903 1253124 1254122 1254123 1254172 1254190 1254203 1254578 1255954 1255956 1257194 1258999 1260259 1260725 1261308 1261329 1261342 1262936 1263862 1263865 1263868 1263870 1263871 1263874 1263879 1263884 1263886 1263895 1263902 1264612 1264823 1264948 1264954 1264961 1264998 1265690 1265693 1268309 1269710 1269722 1269755 1269756 1269759 1278193 1278839 1282743 1282986 1284485 1284491 1285217 1285927 1285934 1287411 1287412 1292564 1293311 1296661 1296667 1296669 1297142 1298355 1298776 1298804 1299103 1299106 1302411 1302417 1303015 1305791 1315946 1328151
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-05 03:13 PDT by Christian Holler (:decoder)
Modified: 2017-01-02 07:02 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Christian Holler (:decoder) 2013-09-05 03:13:03 PDT
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.
Comment 1 User image Jan de Mooij [:jandem] 2013-09-05 03:37:34 PDT
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?
Comment 2 User image Christian Holler (:decoder) 2013-09-05 03:43:09 PDT
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.
Comment 3 User image Jason Orendorff [:jorendorff] 2013-09-05 11:17:34 PDT
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.
Comment 4 User image Gary Kwong [:gkw] [:nth10sd] 2013-09-05 11:25:47 PDT
(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.
Comment 5 User image Terrence Cole [:terrence] 2013-09-05 11:38:52 PDT
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.
Comment 6 User image Jason Orendorff [:jorendorff] 2013-09-05 11:52:37 PDT
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.
Comment 7 User image Naveed Ihsanullah [:naveed] 2013-11-22 09:37:19 PST
Jason and Terrence thanks for taking on this triage

Note You need to log in before you can comment on or make changes to this bug.