252717 - WARNING: writing to output stream failed! data may be lost, file r:/mozilla/netwerk/base/src/nsFileStreams.cpp, line 598

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[timeless]

WARNING: writing to output stream failed! data may be lost, file 
r:/mozilla/netwerk/base/src/nsFileStreams.cpp, line 598

>	necko.dll!nsSafeFileOutputStream::Write(const char * buf=0x066c3a30, 
unsigned int count=0x00000000, unsigned int * result=0x80470002)  Line 598
	C++
 	necko.dll!nsBufferedOutputStream::Flush()  Line 560	C++
 	necko.dll!nsBufferedOutputStream::Close()  Line 511 + 0x10	C++
 	necko.dll!nsBufferedOutputStream::~nsBufferedOutputStream()  Line 127 + 
0x1f	C++
 	necko.dll!nsBufferedOutputStream::`scalar deleting destructor'()  + 0x8
	C++
 	necko.dll!nsBufferedStream::Release()  Line 85 + 0x55	C++
 	necko.dll!nsCookieService::Write()  Line 1134 + 0x22	C++
 	necko.dll!nsCookieService::DoLazyWrite(nsITimer * aTimer=0x06b9ffa0, 
void * aClosure=0x03551078)  Line 734	C++
 	xpcom.dll!nsTimerImpl::Fire()  Line 383 + 0x7	C++

The code should not do what it does if it's asked to write zero bytes.

Comment 1

[[e-mail]]

this shouldn't happen. if Finish() was called correctly before the stream was
destroyed, then the nsBufferedOutputStream's mStream will be null, and it's not
possible to get to Write() from Flush() as your stack shows.

how old is your pull?

Comment 2

[[e-mail]]

it's hard to keep up sometimes, isn't it, timeless? ;)

Comment 3

[timeless]

The assertion is wrong and should be fixed for the 0 byte case.

Comment 4

[[e-mail]]

can you show me how it asserts in the zero byte case?

http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsFileStreams.cpp#596

if count == 0, *result should == count and no problem. unless the stream was
already closed and so the Write() call failed - but that'll happen for any of
the other file impls, and it's a braindead case, right?

Comment 5

[timeless]

you seem to sum up what happened :).

Comment 6

[[e-mail]]

then go fix all the other filestream impls :)

in your trunk, it was a side effect of my hack. in current trunk, it's a useful
warning, and excepting it for the zero byte case seems strange to me.

Comment 7

[[e-mail]]

you win. i checked in a fix for the assert.