842941 - OOM crash in nsMemoryImpl::Alloc

Status: RESOLVED DUPLICATE of bug 943511

(Core :: XPCOM, defect, P2)

Description

[Scoobidiver (away)]

It's #21 top browser crasher in the first hours of 19.0.

The first frames of the stack traces look like:
Frame 	Module 	Signature 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:23
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:27
2 	mozalloc.dll 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:56
3 	xul.dll 	nsMemoryImpl::Alloc 	xpcom/base/nsMemoryImpl.cpp:35
4 	xul.dll 	nsSegmentedBuffer::AppendNewSegment 	xpcom/io/nsSegmentedBuffer.cpp:71
5 	xul.dll 	nsPipe::GetWriteSegment 	xpcom/io/nsPipe3.cpp:463
6 	xul.dll 	nsPipeOutputStream::WriteSegments 	xpcom/io/nsPipe3.cpp:1086

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+|+nsMemoryImpl%3A%3AAlloc%28unsigned+int%29

Comment 1

[Scoobidiver (away)]

It's #19 top browser crasher in 19.0.

It's slightly correlated to anti-virus extensions (AVG and Avast):
* February 16:
      9% (5/55) vs.   1% (481/53060) {0153E448-190B-4987-BDE1-F256CADA672F}
     11% (6/55) vs.   5% (2472/53060) [e-mail]
     89% (49/55) vs.  83% (44237/53060) [e-mail] (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
      9% (5/55) vs.   4% (1923/53060) {EEE6C361-6118-11DC-9C72-001320C79847}
* February 18:
     12% (8/66) vs.   5% (2555/49302) [e-mail]
      8% (5/66) vs.   1% (583/49302) statuswinks@StatusWinks
      6% (4/66) vs.   0% (69/49302) 6offxtbr@HeroicPlay_6o.com
      6% (4/66) vs.   0% (215/49302) 4jffxtbr@RadioRage_4j.com
      9% (6/66) vs.   4% (1786/49302) [e-mail]
      6% (4/66) vs.   1% (484/49302) {E71B541F-5E72-5555-A47C-E47863195841}
* February 20:
      9% (8/91) vs.   3% (1737/61447) avg@toolbar
* February 22:
     21% (90/420) vs.   3% (5729/187421) avg@toolbar
      7% (29/420) vs.   2% (2954/187421) [e-mail] (Java Quick Starter, http://java.sun.com/javase/downloads/)

Comment 2

[Alex Keybl [:akeybl]]

I went through the comments and did not find any correlations there. We need to perform exploratory testing, and then reach out to AVG (we have a contact).

Benjamin - any other ideas of how to move forward here besides exploratory testing before reaching out to AVG?

Comment 3

[u279076]

I've been doing some exploratory testing (using toolbar functions, resetting search provider, and some commone sites (Facebook, Gmail, Youtube, Yahtoo mail, etc) but I've not yet experienced a crash. That said, I've been testing on Windows 7 and having reviewed the crash stats, this is more highly correlated to Windows XP. I'm going to move over to my WinXP VM and try out there.

FYI, I'm testing with Firefox 19.0 and AVG SafeGuard Toolbar 14.2.0.1.

Comment 4

[Benjamin Smedberg]

I looked at a couple crashes, and they appear to be "true" OOM crashes. At least, https://crash-stats.mozilla.com/report/index/6aa4188f-d11f-4d51-93a3-6c78c2130225 has less than 5MB of page file left, and if something in the system hit the pagefile limit at all, we might just be crashing due to OOM.

I don't think this has much to do with any particular vendor. The correlations don't look that high. That said, we should probably make the particular function here (nsSegmentedBuffer::AppendNewSegment) OOM-safe. It looks like of the two callers, nsStorageStream is properly null-checked, and nsPipe::GetWriteSegment at least has some null-checking, although it looks like it assumes that a null return means that the buffer is full, not OOM, and that propagates back to nsPipeOutputStream::WriteSegments. I'd like somebody from networking to verify that the behavior of nsPipe will continue to be correct...

Comment 5

[Jason Duell]

I don't know nsPipe well, but glancing at the code it looks like if we get null from OOM instead of full pipe, we wind up waiting on mReentrantMonitor until something tells us pipe is no longer full (i.e. something sets mBlocked and then checks it in OnOutputWritable).  I wouldn't count on that?  So perhaps we'd need another arg so we could distinguish between OOM and a full pipe.

Comment 6

[Jeff Walden [:Waldo]]

I think the proper fix is to change nsSegmentedBuffer::AppendNewSegment to return nsresult and pointer both.  Right now nullptr means *either* OOM, *or* that the segmented buffer's max size was reached -- as set by nsSegmentedBuffer::Init.  If every segmented buffer had infinite size then you'd only have OOMs, but I don't think this happens in practice.  So really if you're writing to a non-blocking pipe outputstream you want to claim a partial write if that's what happened (regardless whether failure was from OOM or buffer-full), claim would-block if the pipe's full but no OOM happened, and claim OOM if nothing got written and OOM failure happened.  And if you're writing to a blocking pipe outputstream, you want to claim partial write if that's what happened (regardless if OOM or buffer-full at an intermediate state), block if the pipe's full and no OOM, and claim OOM  if nothing got written and OOM failure happened.

It's possible this conflation isn't actually a problem, but I'm having trouble understanding the state-space with things conflated this way.  This confusion suggests splitting things up a bit would be much more understandable than the current setup, modified to account for OOM in some super-minimal way -- even if super-minimal modification can actually work, which I can't really tell.  I don't think there's much more code needed to implement nsresult-plus-array than to implement something OOM-handling without changing any signatures.

Comment 7

[Mihai Morar, (:MihaiMorar)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #3)
> I've been doing some exploratory testing but I've not yet experienced a crash. 

I've done some intense exploratory tests around AVG Security Toolbar (13.2.0.5) and AVG Safe Search (12.0.0.2222)  and it's features based on Comment 1 and on AVG crash percentage from same comment, but I was not able to crash FF.

Even so I got some weird Errors in Error Console about AVG Toolbar as:

1)
Error: SyntaxError: syntax error
Source File: http://toolbar.avg.com/js/sitesafetyjs?v=lZmdW_BLXNoH0qvgdyueQHhdGDOoA-qhulYuNrDPM2o1
Line: 1
Source Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//E

2)
Error: ReferenceError: loadNativeParams is not defined
Source File: http://toolbar.avg.com/widgets/sitesafety/verdict/verdict.aspx?cid=%7B3a5335e5-cee4-4227-b373-b9654881b733%7D&mid=67d147cc1afc47d0a0534b71bda53f1c-2e1e7df8c2c7ae4363bd598709fc9e0d1749292c&ds=AVG&v=13.2.0.5&lang=en&pr=pr&d=2012-11-02%2014%3A09%3A50
Line: 30

3)
Error: downloadable font: not usable by platform (font-family: "DINPro-Medium" style:normal weight:bold stretch:normal src index:2)
source: http://toolbar.avg.com/css/fonts/dinpro-medium.otf
Source File: http://toolbar.avg.com/css/sitesafetycss?v=de-GSN5_urB2leFPTZnX8qWxo2QkymhkfPMNeuy6edI1
Line: 0
Source Code:
@font-face {   font-family: "DINPro-Medium";   font-style: normal;   font-weight: bold;   src: url("fonts/dinpro-medium.eot?#iefix") format("eot"), url("fonts/dinpro-medium.svg") format("svg"), url("fonts/dinpro-medium.otf") format("opentype"), url("fonts/dinpro-medium.woff") format("woff"); }

4)
Error: not well-formed
Source File: http://stats.avg.com/Services/te.asmx/insert?ClientID=%7B3a5335e5-cee4-4227-b373-b9654881b733%7D&MachineID=67d147cc1afc47d0a0534b71bda53f1c-2e1e7df8c2c7ae4363bd598709fc9e0d1749292c&DistributionSource=AVG&Version=13.2.0.5&Language=en&Profile=pr&InstallDate=2012-11-02%2014%3A09%3A50&AdditionalInfoXML=&ElementType=toolbarbutton&ElementName=ClearRecentHistory&Action=click&ElementAdditionalInfo=
Line: 1, Column: 7
Source Code:
GIF89a

5)
Error: this.docShell is null
Source File: chrome://global/content/bindings/browser.xml
Line: 323

Not sure if theese results can help you a lot, but in this moment it's all I got. I can try any other kind of exploratory, edge or feature testing that you think can help in resolving this.

Comment 8

[Mihai Morar, (:MihaiMorar)]

(In reply to MarioMi (:MarioMi) from comment #7)

In addition, most comments from Soccoro said that FF crashed immediately after loading, while reading posts or while switching to another website address. This may be a good start for investigating ?

Comment 9

[Mihai Morar, (:MihaiMorar)]

(In reply to MarioMi (:MarioMi) from comment #7)

AVG Safe Search was disable while testing. Sorry for incorect affirmation.

Comment 10

[Paul Silaghi, QA [:pauly]]

I've been doing some exploratory testing on FF 19 with AVG Security Toolbar 8.0.0.40.2 and avast! WebRep 7.0.1474 but no crashes so far.

Comment 11

[u279076]

Dropping qawanted from this bug as per discussion in today's channel meeting. We've been unable to reproduce and the correlations to AVG are fairly low. Alex Keybl noted that if we have some "padding" we can introduce to mitigate these crashes we'll do so in Firefox 20.

Comment 12

[Scoobidiver (away)]

It dropped down to #34 top browser crasher in 19.0.