Confirmed users
699
edits
Platform/InfallibleMalloc: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
* 1-800-707-2533 (pin 369) Conf# 8605 (US) | * 1-800-707-2533 (pin 369) Conf# 8605 (US) | ||
* join irc.mozilla.org #planning for back channel | * join irc.mozilla.org #planning for back channel | ||
Jesse's notes from platform meeting: | |||
* Infallible malloc <small>(added to agenda by Jesse)</small> | |||
** The problem, which has only recently come to light: | |||
*** We haven't actually made <code>malloc</code> infallible yet. We already made <code>new</code> infallible for Firefox 4, but many data structures (including arrays and strings) can still misbehave on OOM because [https://bugzilla.mozilla.org/show_bug.cgi?id=611123 <code>malloc</code> can still return NULL]. | |||
*** Many exploitable OOM bugs are in system libraries rather than Firefox itself. Replacing <code>malloc</code> may be the <em>only</em> way for us to work around all of these bugs. | |||
*** Security researchers have been reporting many OOM bugs lately. | |||
**** We often can't reproduce what they see because we OOM slightly earlier or later. | |||
**** This is a recipe for embarrassment when "old" testcases find "new" bugs, as Alex Miller [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=504342,583077,606714 discovered]. | |||
** The plan of record: | |||
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=610823 Fix <code>nsTArray</code>] | |||
** Proposal: | |||
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=611123 Make <code>malloc</code> infallible] | |||
*** Fix too-large-allocation crashes (distinct from OOM), which will be obvious in crash-stats. | |||
**** Will require exposing a fallible malloc somehow | |||
**** May require adding methods or variants to string classes, for example. | |||
** We must run GC and purge caches before giving up or we will have false positive OOMs when tons of memory is not actually live. | |||
*** Need to monitor OS memory pressure and avoid getting close to these false OOMs. | |||
*** This was part of E10s, is it ready for Firefox 4? | |||
** Damon will organize a smaller meeting later today to discuss this. Email him if you want to be part of that meeting. | |||
* Crash reporter | |||
** integral part of any proposal: need to get dumps and backtraces from aborts to know where we've missed sites that should use fallible allocation | |||
** have evidence that suggests it might not be dealing well with low memory | |||
*** {{bug|615798}}: No symbols from OOM-abort backtrace | |||
*** {{bug|???}}: (problems OOM'ing on windows) | |||
** ergo, need to test breakpad in low-memory environments | |||