Closed
Bug 938794
Opened 11 years ago
Closed 11 years ago
Annotate OOM sizes for infallible XPCOM structures
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
Tracking | Status | |
---|---|---|
firefox26 | --- | unaffected |
firefox27 | + | fixed |
firefox28 | --- | fixed |
People
(Reporter: benjamin, Assigned: benjamin)
References
Details
(Whiteboard: [qa-])
Attachments
(2 files)
20.64 KB,
patch
|
froydnj
:
review+
|
Details | Diff | Splinter Review |
19.96 KB,
patch
|
bajaj
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
We have infallible XPCOM data structures which currently do NS_RUNTIMEABORT("OOM") if allocation fails. This means that the allocation size isn't annotated in the crash report, and so it's hard to distinguish cases where we're allocating stupidly-large data from other cases. See bug 767343 for some background.
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #832480 -
Flags: review?(nfroyd)
Comment 2•11 years ago
|
||
Comment on attachment 832480 [details] [diff] [review] Annotate OOM size as infallible string or data structures abort Review of attachment 832480 [details] [diff] [review]: ----------------------------------------------------------------- This is a little weird, since in most of these cases, you're not really reporting the actual allocation, but some number from which the actual allocation can be derived. I guess the reasoning here is that the actual allocation size and the already-allocated size are close enough (a factor of 2 or so) that they can stand in for each other? That looks like a reasonable assumption.
Attachment #832480 -
Flags: review?(nfroyd) → review+
Assignee | ||
Comment 3•11 years ago
|
||
Comment on attachment 832480 [details] [diff] [review] Annotate OOM size as infallible string or data structures abort In almost all these cases the size is known: most of the methods that report mLength are in-place mutations where we're just converting the potentially sharable string buffer to a mutable string buffer of the same legnth, so the allocation of mLength is accurate (minus one, I guess). The only case where the accurate length isn't really available is the UTF8<->UTF16 conversion routines where the actual needed size is buried in conversion routine, but the estimation there ought to be good enough.
Comment 4•11 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > Comment on attachment 832480 [details] [diff] [review] > Annotate OOM size as infallible string or data structures abort > > In almost all these cases the size is known OK, great! Thanks for the clarification.
Assignee | ||
Comment 5•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/3bee396bb681 I'd like to take this in 27 as well for OOM analysis.
tracking-firefox27:
--- → +
Target Milestone: --- → mozilla28
https://hg.mozilla.org/mozilla-central/rev/3bee396bb681
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•10 years ago
|
||
[Approval Request Comment] Bug caused by (feature/regressing bug #): Better data needed on OOM crashes User impact if declined: not knowing which crashes are important Testing completed (on m-c, etc.): landed, no known regressions, Risk to taking this patch (and alternatives if risky): low risk - code runs only in OOM cases where we're going to crash anyway String or IDL/UUID changes made by this patch: None
Attachment #8341747 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Updated•10 years ago
|
Attachment #8341747 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 8•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/ec081a4840ca
Keywords: checkin-needed
I don't think this needs QA verification. If anyone thinks that's a mistake please remove the [qa-] whiteboard tag and add the verifyme keyword.
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•