Closed Bug 731083 Opened 11 years ago Closed 4 years ago

OOM Crash [@ __memmove_ssse3_back] due to fallible allocation in nsStringBuffer

Categories

(Core :: XPCOM, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: decoder, Unassigned)

References

Details

(Keywords: crash)

Crash Data

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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Closing because no crash reported since 12 weeks.
You need to log in before you can comment on or make changes to this bug.