nsXMLHttpRequest::SendAsBinary should not use NS_Alloc

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
6 years ago
a year ago

People

(Reporter: emk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
NS_Alloc became infallible by bug 680556.
Contents should not be able to crash the browser.
> 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

6 years ago
NS_Alloc used to use moz_malloc, and now it uses moz_xmalloc, so moz_malloc should be a fine choice.
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?
(Reporter)

Comment 4

6 years ago
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

6 years ago
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.
(Reporter)

Comment 6

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

Comment 7

a year ago
Support for sendAsBinary was removed in bug 853162, so this bug is no longer valid.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.