670553 - ABORT: didn't read as much as was available: 'n == aCount'

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Bob Clary [:bc] (inactive)]

1. http://cms.sc.edu.my/course/view.php?id=549
2. Abort 

I reproduced locally on Mac OS X 10.5 with an Aurora build from 7/8 but not a Nightly from 7/8. I just rebuilt Nightly and could reproduce there. Not sure this is a regression though.

###!!! ABORT: didn't read as much as was available: 'n == aCount', file /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsUnicharStreamLoader.cpp, line 177

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0001af44 in TouchBadMemory () at /work/mozilla/builds/aurora/mozilla/memory/mozalloc/mozalloc_abort.cpp:65
65	    gDummyCounter += *p;   // TODO annotation saying we know 
(gdb) bt
#0  0x0001af44 in TouchBadMemory () at /work/mozilla/builds/aurora/mozilla/memory/mozalloc/mozalloc_abort.cpp:65
#1  0x0001af9f in mozalloc_abort (msg=0xbfffcaa0 "###!!! ABORT: didn't read as much as was available: 'n == aCount', file /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsUnicharStreamLoader.cpp, line 177") at /work/mozilla/builds/aurora/mozilla/memory/mozalloc/mozalloc_abort.cpp:86
#2  0x0651e7a1 in Abort (aMsg=Could not find the frame base for "Abort(char const*)".
) at /work/mozilla/builds/aurora/mozilla/xpcom/base/nsDebugImpl.cpp:388
#3  0x0651ed4a in NS_DebugBreak_P (aSeverity=3, aStr=0x6c6d380 "didn't read as much as was available", aExpr=0x6c6d374 "n == aCount", aFile=0x6c6d284 "/work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsUnicharStreamLoader.cpp", aLine=177) at /work/mozilla/builds/aurora/mozilla/xpcom/base/nsDebugImpl.cpp:345
#4  0x04dcd689 in nsUnicharStreamLoader::OnDataAvailable (this=0x24f32110, aRequest=0xe88a34, aContext=0x0, aInputStream=0x24a7f270, aSourceOffset=0, aCount=67) at /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsUnicharStreamLoader.cpp:177
#5  0x04dcb2b0 in nsStreamListenerTee::OnDataAvailable (this=0x24f61c20, request=0xe88a34, context=0x0, input=0x24f36eac, offset=0, count=67) at /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsStreamListenerTee.cpp:111
#6  0x04e856a9 in nsHttpChannel::OnDataAvailable (this=0xe88a00, request=0x24f36fd0, ctxt=0x0, input=0x24f36eac, offset=0, count=67) at /work/mozilla/builds/aurora/mozilla/netwerk/protocol/http/nsHttpChannel.cpp:4287
#7  0x04d90945 in nsInputStreamPump::OnStateTransfer (this=0x24f36fd0) at /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsInputStreamPump.cpp:510
#8  0x04d90e5c in nsInputStreamPump::OnInputStreamReady (this=0x24f36fd0, stream=0x24f36eac) at /work/mozilla/builds/aurora/mozilla/netwerk/base/src/nsInputStreamPump.cpp:400


Aurora/Firefox 7 Windows 7; Beta/Firefox 6, Aurora/Firefox 7, Nightly/Firefox 8  Mac OS X 10.5
NS_DebugBreak_P | nsUnicharStreamLoader::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsStreamListenerTee::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsInputStreamPump::OnStateTransfer() nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*)

Beta/Firefox 6, Aurora/Firefox 7 Linux x86_64
mozalloc_abort | Abort | NS_DebugBreak_P | nsAutoPtr<nsTArray<mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::ResourceAcquisition, nsTArrayDefaultAllocator> >::operator nsTArray<mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::ResourceAcquisition, nsTArrayDefaultAllocator>* mozilla::BlockingResourceBase::CheckAcquire PR_GetCurrentThread PR_SetThreadPrivate mozilla::BlockingResourceBase::ResourceChainRemove

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix assertion

This can happen if aInputStream actually has more than aCount bytes to hand back, which can apparently happen in some cases....  we were ending up with toRead > aCount and hence n > aCount.  In this case it's safe, I think, but better to not do that.

Comment 2

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/89c6076be041

Comment 3

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/89c6076be041