771780 - crash in nsFileStreamBase::Write

Status: RESOLVED DUPLICATE of bug 597260

(Core :: Networking, defect)

Description

[Scoobidiver (away)]

It's #32 top browser crasher in 15.0a2 and #196 in 16.0a1.

If first appeared in 15.0a1/20120524030520. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36e938e51481&tochange=f43e8d300f21

It stopped spiking after 16.0a1/20120609030536. The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95d1bb200f4e&tochange=dc410944aabc

There are two kinds of stack trace:
Frame 	Module 	Signature 	Source
0 		@0xd71007b 	
1 		@0xd705178 	
2 	xul.dll 	nsFileStreamBase::Write 	netwerk/base/src/nsFileStreams.cpp:226
3 	xul.dll 	nsSafeFileOutputStream::Write 	netwerk/base/src/nsFileStreams.cpp:796
4 	xul.dll 	nsBufferedOutputStream::Flush 	netwerk/base/src/nsBufferedStreams.cpp:606
5 	xul.dll 	nsBufferedOutputStream::Write 	netwerk/base/src/nsBufferedStreams.cpp:589
6 	xul.dll 	mozilla::Preferences::WritePrefFile 	modules/libpref/src/Preferences.cpp:735
7 	xul.dll 	mozilla::Preferences::SavePrefFileInternal 	modules/libpref/src/Preferences.cpp:665
8 	xul.dll 	mozilla::Preferences::SavePrefFile 	modules/libpref/src/Preferences.cpp:423
9 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70
10 	xul.dll 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:2401
11 	xul.dll 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1500
12 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:310
13 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2512
14 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:326
...

Frame 	Module 	Signature 	Source
0 		@0x16c26f 	
1 		@0x15d30c 	
2 	xul.dll 	nsFileStreamBase::Write 	netwerk/base/src/nsFileStreams.cpp:226
3 	xul.dll 	nsSafeFileOutputStream::Write 	netwerk/base/src/nsFileStreams.cpp:796
4 	xul.dll 	nsStreamCopierIB::ConsumeInputBuffer 	xpcom/io/nsStreamUtils.cpp:486
5 	xul.dll 	nsPipeInputStream::ReadSegments 	xpcom/io/nsPipe3.cpp:766
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsFileStreamBase%3A%3AWrite%28char+const*%2C+unsigned+int%2C+unsigned+int*%29

Comment 1

[Alex Keybl [:akeybl]]

Hey Josh - could somebody from your team look through the suspected regression range and make recommendations on what we should consider investigating further (or speculativey back out)? There aren't a lot of comments in the crash itself, and I believe this crash is correlated to a Firefox change as opposed to an external variable. Thanks in advance.

Comment 2

[Josh Aas]

Around the regressions range, Jan Varga had this change to 'nsFileStreams.cpp':

a301e1c41b7d, 2012-05-23 06:23: Jan Varga - Bug 757507 - Implement read-write file streams. r=biesi

This modifies the file containing the last resolved symbol in the stack. Then later on in the fixed range he has these fixes:

Sat Jun 09 13:57:50 2012
6a2100ce978f: Jan Varga — Bug 763157 - FileHandle: Fix the assertion in FileHelper::~FileHelper. r=bent
72419c5d84df: Jan Varga — Bug 763013 - Race condition in async stream copier. r=biesi

I don't have strong evidence for this, just something that looked suspicious.

CC'd Jan and Michal.

Comment 3

[Alex Keybl [:akeybl]]

Hi Jan, can you look into this crash? Josh suspects this may be caused by bug 757507. If we're unsure, I'd like to speculatively back out bug 757507 from beta very early in the cycle.

Comment 4

[Jan Varga [:janv]]

I re-reviewed my patch multiple times and I couldn't find anything that could cause this crash. I also tried to create a test which would trigger the crash, however I never experienced the crash.
 
It seems this crash is not new (and thus unrelated to my nsFileStream changes), the crash happens in Firefox 14.0.1 too. See bug 574996 and bug 597260

Comment 5

[Jan Varga [:janv]]

FYI, nsFileStreamBase::Write() now appears in the stack trace because I moved some code to the base class.
PR_Write() used to be called from nsFileOutputStream::Write() directly, now it's called from nsFileStreamBase::Write()
So, I think it's the same crash as in bug 597260