705035 - nsXMLHttpRequest::SendAsBinary should not use NS_Alloc

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Masatoshi Kimura [:emk]]

NS_Alloc became infallible by bug 680556.
Contents should not be able to crash the browser.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> NS_Alloc became infallible by bug 680556.

So how does one do a fallible allocation guaranteed to come from the heap NS_Free frees from?

Comment 2

[Josh Matthews [:jdm]]

NS_Alloc used to use moz_malloc, and now it uses moz_xmalloc, so moz_malloc should be a fine choice.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is true if you're guaranteed to be in the same library as nsMemoryImpl.cpp.  Is that true for all NS_Alloc users?  I sort of doubt it...  If you're not in the same library, then I'm not entirely sure a direct moz_malloc call is equivalent.

For XHR, they're possibly both in libxul right now, of course, so it might be ok.  What about other consumers?

Comment 4

[Masatoshi Kimura [:emk]]

At least js is not inside the same library on Windows (until js has been folded into libxul again).
https://mxr.mozilla.org/mozilla-central/search?string=NS_Alloc&find=%2Fjs%2F&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

Comment 5

[Benjamin Smedberg]

JS is irrelevant since it doesn't use XPCOM functions. Within gecko code they are definitely equivalent. We could certainly add a NS_FallibleAlloc but I'm not sure that's necessary.

Comment 6

[Masatoshi Kimura [:emk]]

So, what about removing NS_Alloc? Is it still required for libxul era?

Comment 7

[Thomas Wisniewski]

Support for sendAsBinary was removed in bug 853162, so this bug is no longer valid.