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)
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:
Reporter | ||
Updated•23 years ago
|
Comment 4•23 years ago
|
||
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
Assignee | ||
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 6•23 years ago
|
||
I don't see this any longer, either. Go ahead and verify.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•