Closed Bug 966870 Opened 8 years ago Closed 8 years ago

JSONP and a huge file crashes with a large infallible allocation at nsStreamLoader::OnStartRequest


(Core :: Networking, defect)

26 Branch
Windows 7
Not set





(Reporter: ali.of.south, Assigned: lpy)


(Blocks 1 open bug)


(Whiteboard: [][lang=c++][good first bug])


(2 files)

Attached file index.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

I run an html file with this code:
<!DOCTYPE html>
			<meta charset="UTF-8" />
			<script type="text/javascript" src=""></script>
			<script type="text/javascript">
						dataType: 'jsonp',
  						url: '',
  						success: function () {

Actual results:

Firefox crashed!

Expected results:

Firefox simply should download my file
do you have a crash signature? If not can you get one from about:crashes?
Flags: needinfo?(ali.nowruzi)
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

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.
Crash ID:
Flags: needinfo?(ali.nowruzi)
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.
Blocks: 943017
Group: core-security
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: [][lang=c++][good first bug] 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?
Assignee: nobody → pylaurent1314
Attached patch bug966870.patchSplinter Review
Attachment #8369894 - Flags: review?(benjamin)
Attachment #8369894 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.