Closed Bug 966870 Opened 6 years ago Closed 6 years ago
JSONP and a huge file crashes with a large infallible allocation at ns
Stream Loader::On Start Request
do you have a crash signature? If not can you get one from about:crashes?
There are a couple things going on here: 1) you told jquery that this was JSONP: this means we try to load the URL as JS. It doesn't make any sense to try and load an .iso as JS: presumably what you actually wanted was to either link to the ISO (so that the user could save it to disk) or to do something with the data in webpage JS, in which case you need to read https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data 2) Please provide the crash ID from about:crashes. Firefox will intentionally and safely crash if we run out of memory in many cases, so unless this is an unsafe crash we don't need to leave this bug security-private.
ok. That's an intentional crash and not a security issue by itself. (It is a DOS, but we don't keep those hidden.) This is an allocation site that should be using fallible allocation and failing to load when allocation fails.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
Summary: JSONP and a huge file → JSONP and a huge file crashes with a large infallible allocation at nsStreamLoader::OnStartRequest
Whiteboard: [email@example.com][lang=c++][good first bug]
http://hg.mozilla.org/releases/mozilla-release/annotate/39faf812aaec/netwerk/base/src/nsStreamLoader.cpp#l81 is the code link. This should probably be using moz_malloc instead of NS_Alloc and that might be sufficient all by itself. A test would be nice, but I'm not sure we currently have a simple way to test OOM behavior like this. Maybe we need an xpcshell API to cap the jemalloc heap size?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.