Closed Bug 127323 Opened 23 years ago Closed 23 years ago

Memory leak of 2048 bytes from 1 block allocated in nsSegmentedBuffer::AppendNewSegment

Categories

(Core :: XPCOM, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED INVALID
mozilla1.2alpha

People

(Reporter: stephend, Assigned: badami)

Details

(Keywords: memory-leak)

Build ID: latest win32 tip running Purify. Sorry all, I don't know if this is bogus or not, but I've never seen this until recently. Steps to Reproduce: 1. Send yourself mail to an IMAP account (this is part of the setup, not the leak), make sure you have 'check for new mail at startup' checked in the Account Manager. 2. Launch a fresh run of Mozilla -mail (this will have the new message appear in your INBOX). 3. Shutdown. [W] MLK: Memory leak of 2048 bytes from 1 block allocated in PR_Malloc Distribution of leaked blocks Allocation location malloc [MSVCRT.DLL] PR_Malloc [prmem.c:402] nsMemoryImpl::Alloc(UINT) [nsMemoryImpl.obj:320] nsSegmentedBuffer::AppendNewSegment(void) [nsSegmentedBuffer.cpp:117] mSegmentArrayCount = newArraySize; } => char* seg = (char*)mSegAllocator->Alloc(mSegmentSize); if (seg == nsnull) { return nsnull; } nsPipe::GetWriteSegment(char * *,UINT *) [nsPipe2.cpp:304] *resultSegmentLen = 0; if (mWriteCursor == nsnull || mWriteCursor == mWriteLimit) { => char* seg = mBuffer.AppendNewSegment(); if (seg == nsnull) { // buffer is full return NS_OK; nsPipe::nsPipeOutputStream::WriteSegments((*)(nsIOutputStream *,void *,char *,UINT,UINT,UINT *),void *,UINT,UINT *) [nsPipe2.cpp:698] while (amt > 0) { PRUint32 writeBufLen; char* writeBuf; => rv = pipe->GetWriteSegment(&writeBuf, &writeBufLen); if (NS_FAILED(rv)) goto done; if (writeBufLen == 0) { nsPipe::nsPipeOutputStream::WriteFrom(nsIInputStream *,UINT,UINT *) [nsPipe2.cpp:854] nsPipe::nsPipeOutputStream::WriteFrom(nsIInputStream* fromStream, PRUint32 count, PRUint32 *writeCount) => { return WriteSegments(nsReadFromInputStream, fromStream, count, writeCount); } nsStreamListenerProxy::OnDataAvailable(nsIRequest *,nsISupports *,nsIInputStream *,UINT,UINT) [nsStreamListenerProxy.cpp:303] // that the pipe was emptied during this time, we retry copying data // into the pipe. // => rv = mPipeOut->WriteFrom(source, count, &bytesWritten); LOG(("nsStreamListenerProxy: Wrote data to pipe [rv=%x count=%u bytesWritten=%u req=%x]\n", rv, count, bytesWritten, request)); nsSocketReadRequest::OnRead(void) [nsSocketTransport.cpp:2871] mContext, mInputStream, offset, => amount); LOG(("nsSocketReadRequest: listener returned [rv=%x]\n", rv)); nsSocketTransport::doReadWrite(short) [nsSocketTransport.cpp:1077] // we must not call out to our listener with the monitor held. mReadRequest // can only be cleared on this thread, so releasing the monitor should be safe. PR_ExitMonitor(mMonitor); => readStatus = mReadRequest->OnRead(); PR_EnterMonitor(mMonitor); if (mReadRequest->IsSuspended()) { mSelectFlags &= ~PR_POLL_READ; nsSocketTransport::Process(short) [nsSocketTransport.cpp:541] LOG(("nsSocketTransport: Transport [host=%s:%d this=%x] " "is in WaitReadWrite state [readtype=%x writetype=%x status=%x].\n", mHostName, mPort, this, GetReadType(), GetWriteType(), mStatus)); => mStatus = doReadWrite(aSelectFlags); break; case eSocketState_Timeout:
to neeti.
Assignee: dougt → neeti
Target Milestone: --- → mozilla1.0
cc'ing darin
-> badami
Assignee: neeti → badami
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Stephen I'am unable to reproduce this. I could not purify it since my purified mozilla is crashing for whatever reason. However, I added logging into the code to track creation/destruction of the nsPipe and nsPipeInputStream objects and i find that all objects of this class that are created are also destroyed. If all these these ojects are destroyed, then they would be giving up the segments that they own. Can u please give this one more try with purify. Please increase the call stack lengths to 50 under settings before u run it.
I don't see this any longer, either. Go ahead and verify.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.