764342 - OOM crash in nsSegmentedBuffer::AppendNewSegment

Status: RESOLVED DUPLICATE of bug 943511

(Core :: XPCOM, defect)

Description

[Scoobidiver (away)]

It's #103 top browser crasher in 13.0.
On Mac, it's #16 top browser crasher in 13.0 and #23 in 14.0b6.

It first appeared on Windows in 13.0a1/20120306. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=433cfbd2a0da&tochange=7d0d1108a14e

According to comments, it's related to logging into websites.

Signature 	TouchBadMemory | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | nsSegmentedBuffer::AppendNewSegment More Reports Search
UUID	0578441c-a8e0-4cb3-a1a7-c2a4a2120608
Date Processed	2012-06-08 01:16:30
Uptime	24
Last Crash	1.1 minutes before submission
Install Age	3.8 hours since version was first installed.
Install Time	2012-06-07 21:24:47
Product	Firefox
Version	13.0
Build ID	20120601045813
Release Channel	release
OS	Mac OS X
OS Version	10.5.8 9L31a
Build Architecture	x86
Build Architecture Info	family 6 model 23 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x0
User Comments	Good evening. I login to any website and firefox crashes. I was on a government site and it tried to go to a link and got stuck trying to process the command. Thank you for your help.
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a02
EMCheckCompatibility	True	
OOMAllocationSize	4096

Bugzilla - Report this bug in Firefox, Core, Plug-Ins, or Toolkit
Crashing Thread
Frame 	Module 	Signature 	Source
0 	libmozalloc.dylib 	TouchBadMemory 	memory/mozalloc/mozalloc_abort.cpp:68
1 	libmozalloc.dylib 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:89
2 	libmozalloc.dylib 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:60
3 	libmozalloc.dylib 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:105
4 	XUL 	nsSegmentedBuffer::AppendNewSegment 	xpcom/io/nsSegmentedBuffer.cpp:103
5 	XUL 	nsStorageStream::Write 	xpcom/io/nsStorageStream.cpp:195
6 	XUL 	nsInputStreamTeeWriteEvent::Run 	xpcom/io/nsInputStreamTee.cpp:130
7 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
8 	XUL 	NS_ProcessNextEvent_P 	obj-firefox/i386/xpcom/build/nsThreadUtils.cpp:245
9 	XUL 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:289
10 	libnspr4.dylib 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
11 	libSystem.B.dylib 	_pthread_start 	
12 	libSystem.B.dylib 	thread_start

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+mozalloc_handle_oom%28unsigned+int%29+|+moz_xmalloc+|+nsSegmentedBuffer%3A%3AAppendNewSegment%28%29
https://crash-stats.mozilla.com/report/list?signature=TouchBadMemory+|+mozalloc_abort+|+mozalloc_handle_oom+|+moz_xmalloc+|+nsSegmentedBuffer%3A%3AAppendNewSegment

Comment 1

[Benjamin Smedberg]

I had a custom socorro report run on the allocation sizes here, see bug 766230 attachment 634544 [details] for the raw data, but basically we're aborting on allocations which are in the typical case 32k, sometimes as small as 256 bytes and sometimes as large as 131k. In all cases the reported available memory (both physical and virtual) is well above any threshold for likely "real" OOM. This indicates probable memory corruption, but since these are large allocations they would be in the "medium" allocator, not the "small" bucket allocator.

The only thing that looked at all obviously suspicious to me in the regression range was bug 729940 (better hash functions), but if I'm reading it correctly that landed, was backed out, landed, and was backed out again all within that period, leaving it out at the end.

There's also Bug 468275 - Fix mis-use of _ogg_free on allocation error path, r=kinetik but that only affects libtheora which basically makes it irrelevant, at least unless we have video on firstrun pages or something like that which could be tickling something.

Comment 2

[Timothy B. Terriberry (:derf)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> There's also Bug 468275 - Fix mis-use of _ogg_free on allocation error path,
> r=kinetik but that only affects libtheora which basically makes it
> irrelevant, at least unless we have video on firstrun pages or something
> like that which could be tickling something.

I'm pretty sure it's not bug 468275. If the un-patched code path had ever been executed, it would have segfaulted immediately.

Comment 4

[Rob F]

Attachment: requested @ https://bugzilla.mozilla.org/show_bug.cgi?id=778454#c4

Comment 6

[Scoobidiver (away)]

The reporter of bug 778704 can reproduce the crash with a private file.

Comment 7

[tcleghorn]

Does anyone know the max filesize of an attachment? I've produced an obfuscated (images scrambled and text replaced) version of one of the documents that will reproduce the crash, but it's 3.5GB.

Comment 8

[Justin Lebar (not reading bugmail)]

(In reply to tcleghorn from comment #7)
> Does anyone know the max filesize of an attachment? I've produced an
> obfuscated (images scrambled and text replaced) version of one of the
> documents that will reproduce the crash, but it's 3.5GB.

10mb.  :)

Comment 9

[tcleghorn]

Ouch. So a zip split to 350 volumes, then..? I kid, I'll sort some external hosting out :)

Comment 10

[Benjamin Smedberg]

Did you generate the file using a script? Perhaps just attach that script? Otherwise if the file is a repeating pattern, bzipping it should make it compress extremely well.

Comment 11

[tcleghorn]

No, I didn't generate them - these are HTML renditions of as-yet unpublished academic textbooks, which come my way for QA purposes. It's the images referenced in the HTML which are very large (in this particular instance, there's over 600 of them). They're PNGs, so already quite well compressed... do I remember RAR being good at compressing image data? Maybe I should give that a whirl.

I've just tried opening the file with the images inaccessible, and the crash doesn't occur - so it looks likely that it's images that are actually causing it. Whether it's the quantity and size of them that's at fault or something about the files themselves, I can't say.

Comment 12

[Justin Lebar (not reading bugmail)]

If you're loading a page with 600 large images and then crashing, it's likely you're OOM'ing the browser due to bug 661304.

Comment 13

[tcleghorn]

Looks pretty likely to me. Not sure why we would have only started seeing it with v13+, though - books this sort of size aren't the rule, but they're reasonably common for us. I've had two new ones since reporting bug 778704 for instance.

Comment 14

[Marcia Knous [:marcia]]

This signature showed up in the explosive report for Firefox 16 beta: https://crash-analysis.mozilla.com/rkaiser/2012-09-26/2012-09-26.firefox.16.explosiveness.html

Comment 15

[Scoobidiver (away)]

The first frames of the current stack strace now look like:
Frame 	Module 	Signature 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:30
1 	mozalloc.dll 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:56
2 	xul.dll 	nsSegmentedBuffer::AppendNewSegment 	xpcom/io/nsSegmentedBuffer.cpp:71
3 	xul.dll 	nsPipe::GetWriteSegment 	xpcom/io/nsPipe3.cpp:463
4 	xul.dll 	nsPipeOutputStream::WriteSegments 	xpcom/io/nsPipe3.cpp:1086
5 	xul.dll 	nsHttpTransaction::WriteSegments 	netwerk/protocol/http/nsHttpTransaction.cpp:635
6 	xul.dll 	nsHttpConnection::OnSocketReadable 	netwerk/protocol/http/nsHttpConnection.cpp:1400
7 	xul.dll 	nsHttpConnection::OnInputStreamReady 	netwerk/protocol/http/nsHttpConnection.cpp:1521
8 	xul.dll 	nsSocketInputStream::OnSocketReady 	netwerk/base/src/nsSocketTransport2.cpp:224
9 	xul.dll 	nsSocketTransport::OnSocketReady 	netwerk/base/src/nsSocketTransport2.cpp:1556

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+moz_xmalloc+|+nsSegmentedBuffer%3A%3AAppendNewSegment%28%29