Closed Bug 670553 Opened 10 years ago Closed 10 years ago

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


(Core :: Networking, defect, P1)




Tracking Status
firefox6 --- affected
firefox7 --- affected
firefox8 --- affected


(Reporter: bc, Assigned: bzbarsky)




(Keywords: assertion)


(1 file)

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
Attached patch Fix assertionSplinter Review
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.
Assignee: nobody → bzbarsky
Blocks: 541496
Priority: -- → P1
Whiteboard: [need review]
Attachment #545159 - Flags: review?(zackw)
Attachment #545159 - Flags: review?(zackw) → review+
Whiteboard: [need review] → [need landing]
Whiteboard: [need landing]
Target Milestone: --- → mozilla8
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.