873757 - crash in JSStructuredCloneWriter::writeArrayBuffer

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It's #8 top crasher in 24.0a1 and first showed up in 24.0a1/20130514. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7130e5134a6e&tochange=81dd97739fa1
It's likely a regression from bug 866431.

Signature 	JSStructuredCloneWriter::writeArrayBuffer(JS::Handle<JSObject*>) More Reports Search
UUID	75112060-37b7-4025-8f5b-123b52130518
Date Processed	2013-05-18 13:24:49
Uptime	30
Last Crash	4.0 hours before submission
Install Age	21.9 hours since version was first installed.
Install Time	2013-05-17 15:33:15
Product	Firefox
Version	24.0a1
Build ID	20130517031000
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 30 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x4
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x6899, AdapterSubsysID: 29701682, AdapterDriverVersion: 9.12.0.0
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	sp-processor03_phx1_mozilla_com_17732:2012
EMCheckCompatibility	False
Adapter Vendor ID	0x1002
Adapter Device ID	0x6899
Total Virtual Memory	4294836224
Available Virtual Memory	3629711360
System Memory Use Percentage	34
Available Page File	6877728768
Available Physical Memory	2810765312

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	JSStructuredCloneWriter::writeArrayBuffer 	js/src/jsclone.cpp:605
1 	mozjs.dll 	JSStructuredCloneWriter::startWrite 	js/src/jsclone.cpp:679
2 	mozglue.dll 	arena_bin_nonfull_run_get 	memory/mozjemalloc/jemalloc.c:3890
3 	mozjs.dll 	JSStructuredCloneWriter::write 	js/src/jsclone.cpp:745
4 	mozjs.dll 	js::WriteStructuredClone 	js/src/jsclone.cpp:106
5 	mozjs.dll 	JS_WriteStructuredClone 	js/src/jsapi.cpp:6395
6 	xul.dll 	js::ArrayBufferBuilder::getArrayBuffer 	obj-firefox/dist/include/jsfriendapi.h:1067
7 	mozjs.dll 	JSAutoStructuredCloneBuffer::write 	js/src/jsapi.cpp:6519
8 	xul.dll 	nsAString_internal::Assign 	xpcom/string/src/nsTSubstring.cpp:347
9 	xul.dll 	`anonymous namespace'::EventRunnable::PreDispatch 	dom/workers/XMLHttpRequest.cpp:590
10 	xul.dll 	mozilla::dom::workers::WorkerRunnable::Dispatch 	dom/workers/WorkerPrivate.cpp:1534
11 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:922
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=JSStructuredCloneWriter%3A%3AwriteArrayBuffer%28JS%3A%3AHandle%3CJSObject*%3E%29

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I admit, I'm confused.  JSAutoStructuredCloneBuffer::write definitely does not call js::ArrayBufferBuilder::getArrayBuffer, or uses ArrayBufferBuilder at all.  The only thing that does is XMLHttpRequest right now.

Comment 2

[Scoobidiver (away)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #1)
> I admit, I'm confused. 
So it might be caused by bug 860965.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Scoobidiver from comment #2)
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #1)
> > I admit, I'm confused. 
> So it might be caused by bug 860965.

That looks like it got backed out on 13-May, and there are still crashes beyond that. :/  I wish we would include the offset in the symbol in the stack traces in the display, so that we can see if it's just using the wrong symbol in the stack trace.

Comment 4

[Brendan Dahl [:bdahl]]

I can reproduce with nightly by visiting the following url:
http://people.mozilla.com/~bdahl/sandbox/bug873757/web/viewer.html?file=intelisa.pdf

Comment 5

[Scoobidiver (away)]

(In reply to Brendan Dahl from comment #4)
> I can reproduce with nightly by visiting the following url:
Me too.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix builder when length == 0, and reset XHR

Ah ha!  Awesome, thanks bdahl.

There was a failed assertion before this (at nsXMLHttpRequest::GetResponse -> ArrayBufferBuilder::getArrayBuffer -> JS_NewArrayBufferWithContents, where an assert(contents) was failing), so that null could have caused all this stuff.

The issue was that a 0-length read resulted in us never actually allocating contents, thus passing a null pointer to JS_NewArrayBufferWithContents.

And a bonus, I caught another missing reset(), this time with chunked XHR :/

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 753181 [details] [diff] [review]
fix builder when length == 0, and reset XHR

r=me

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, definitely in-testsuite?.  Things to test:

- loading an arraybuffer
- reusing an XHR to load another arraybuffer
- loading a chunked arraybuffer
- reusing an XHR to load another chunked arraybuffer
- not reading the response property in all of the above before continuing, as well as reading it

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/633a2ef5b0c2

Comment 10

[Paul Silaghi, QA [:pauly]]

Reproduced Nightly 2013-05-17.
No longer reproducible in FF 24b5.
Also there are no crashes checking the crashstats for the last 4 weeks.