The following source part (m-c revision 66e4d53697c2) indirectly uses fallible allocation through the nsStringBuffer class: http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsAtomTable.cpp#334 but crashes when allocation fails with the following trace (the access in line 335 is optimized away it seems): __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1988 1988 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. in ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1988 #1 0x00002aaaad2a3e47 in move (n=<optimized out>, s2=<optimized out>, s1=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:58 #2 write (n=<optimized out>, s=<optimized out>, iter=@0x7fffffff9838) at ../../../dist/include/nsCharTraits.h:819 #3 copy_string<nsReadingIterator<unsigned short>, unsigned short*> (first=<optimized out>, last=<optimized out>, result=@0x7fffffff9838) at ../../../dist/include/nsAlgorithm.h:124 #4 0x00002aaaad2a3f72 in CopyUnicodeTo (aSource=..., aSrcOffset=0, aDest=0x8, aLength=<optimized out>) at /srv/repos/browser/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:390 #5 0x00002aaaad25859e in AtomImpl::AtomImpl (this=0x2aaabc725f90, aString=...) at /srv/repos/browser/mozilla-central/xpcom/ds/nsAtomTable.cpp:336 #6 0x00002aaaad258ee3 in NS_NewAtom (aUTF16String=...) at /srv/repos/browser/mozilla-central/xpcom/ds/nsAtomTable.cpp:660 #7 0x00002aaaac91bedc in do_GetAtom (aUTF16String=<optimized out>) at ../../../dist/include/nsIAtom.h:199 => 0x2aaaab5354ad <__memmove_ssse3_back+8285>: movdqu %xmm0,-0x38(%rdi) The crash itself is harmless but we should handle this situation anyway. I propose we should either make nsStringBuffer::Alloc infallible in general, or if that is not possible, add a second set of infallible methods (like moz_xmalloc).

nsStringBuffer::Alloc needs to remain fallible. The caller needs to properly handle allocation failure here.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #1) > nsStringBuffer::Alloc needs to remain fallible. The caller needs to > properly handle allocation failure here. Is this a unique situation or would it make sense to support infallible operations with a second set of methods on that class?

I don't think it makes sense to make any infallible APIs on string buffers. String buffers are very often used for content controlled lengths of data, leading to trivial DOS with infallible allocation.

DoS is going to be trivial no matter what we do with strings. We do a lot of string manipulation, and a lot of it through APIs like "a += b" that would be a huge pain to check for OOM.

Closing because no crash reported since 12 weeks.

Closing because no crash reported since 12 weeks.