This is the basis of our component technology; this covers the mozilla/xpcom source directory and includes the "repository". Unlikely a tester would be able to tell there was an XPCOM problem specifically.

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.

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.

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.

(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.