Closed Bug 126104 Opened 23 years ago Closed 23 years ago

Memory leak of 3 bytes from 1 block allocated in nsHttpResponseHead::ParseStatusLine

Categories

(Core :: Networking: HTTP, defect, P1)

All
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: stephend, Assigned: badami)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Build ID: Windows 2000 latest trunk as of 6:30 pm today.

Summary: Memory leak of 3 bytes from 1 block allocated in 
nsHttpResponseHead::ParseStatusLine

Steps to Reproduce:

Just start up Mozilla with http://home.netscape.com as your start page.

    [W] MLK: Memory leak of 3 bytes from 1 block allocated in PL_strdup
        Distribution of leaked blocks
        Allocation location
        malloc         [MSVCRT.DLL]
        PL_strdup      [strdup.c:46]
        nsHttpResponseHead::ParseStatusLine(char *) [nsHttpResponseHead.cpp:161]
        
            if ((mVersion == NS_HTTP_VERSION_0_9) || !(line = PL_strchr
(line, ' '))) {
                mStatus = 200;
     =>         mStatusText = nsCRT::strdup("OK");
            }
            else {
                // Status-Code
        ???            [ip=0x08e53719]
        nsHttpTransaction::ParseLine(char *) [nsHttpTransaction.cpp:354]
            LOG(("nsHttpTransaction::ParseLine [%s]\n", line));
        
            if (!mHaveStatusLine) {
     =>         mResponseHead->ParseStatusLine(line);
                mHaveStatusLine = PR_TRUE;
                // XXX this should probably never happen
                if (mResponseHead->Version() == NS_HTTP_VERSION_0_9)
        ???            [ip=0x08b14a8c]
        nsHttpTransaction::ParseLineSegment(char *,UINT) 
[nsHttpTransaction.cpp:379]
                else {
                    // trim off the new line char and parse the line
                    mLineBuf.Truncate(mLineBuf.Length() - 1);
     =>             ParseLine(NS_CONST_CAST(char*,mLineBuf.get()));
                    // stuff the segment into the line buf
                    mLineBuf.Assign(segment, len);
                }
        nsHttpTransaction::ParseHead(char *,UINT,UINT *) 
[nsHttpTransaction.cpp:452]
                    len--;
        
                buf[len-1] = '\n';
     =>         ParseLineSegment(buf, len);
        
                if (mHaveAllHeaders)
                    return NS_OK;
        nsHttpTransaction::Read(char *,UINT,UINT *) [nsHttpTransaction.cpp:865]
            if (!mHaveAllHeaders) {
                PRUint32 bytesConsumed = 0;
        
     =>         rv = ParseHead(buf, count, &bytesConsumed);
                if (NS_FAILED(rv)) return rv;
        
                count -= bytesConsumed;
        nsReadFromInputStream [nsPipe2.cpp:845]
                              PRUint32 offset,
                              PRUint32 count,
                              PRUint32 *readCount)
     => {
            nsIInputStream* fromStream = (nsIInputStream*)closure;
            return fromStream->Read(toRawSegment, count, readCount);
        }
        nsPipe::nsPipeOutputStream::WriteSegments((*)(nsIOutputStream *,void 
*,char *,UINT,UINT,UINT *),void *,UINT,UINT *) [nsPipe2.cpp:721]
                    while (writeBufLen > 0) {
                        PRUint32 readCount = 0;
                        mon.Exit(); // XXX avoid deadlock better
     =>                 rv = reader(this, closure, writeBuf, *writeCount, 
writeBufLen, &readCount);
                        mon.Enter();
                        if (rv == NS_BASE_STREAM_WOULD_BLOCK) {
                            NS_ASSERTION(readCount <= writeBufLen, "reader 
returned bad readCount");
        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));
        nsHttpTransaction::OnDataReadable(nsIInputStream *) 
[nsHttpTransaction.cpp:241]
        
            // let our listener try to read up to NS_HTTP_BUFFER_SIZE from us.
            rv = mListener->OnDataAvailable(this, nsnull, this,
     =>                                     mContentRead, NS_HTTP_BUFFER_SIZE);
        
            LOG(("nsHttpTransaction: listener returned [rv=%x]\n", rv));
        
        nsHttpConnection::OnDataAvailable(nsIRequest *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsHttpConnection.cpp:697]
                nsHttpHandler::get()->ProcessTransactionQ();
            }
        
     =>     nsresult rv = mTransaction->OnDataReadable(inputStream);
        
            LOG(("mTransaction->OnDataReadable() returned [rv=%x]\n", rv));
            return rv;
    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:
This looks small, but I see this repeatedly all over the Purify logs and
sometimes it happens with greater byte counts. (20 bytes occasionally).
-> vinay
Assignee: darin → badami
Call Reset from destructor of nsHttpResponseHead.
Have not been able to test patch under purify.
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Keywords: nsbeta1nsbeta1+
Hardware: PC → All
Comment on attachment 70712 [details] [diff] [review]
to plug leak of nsHttpResponseHead resources

sr=darin  whoops!!
Attachment #70712 - Flags: superreview+
Thanks, guys.  This fixes all nsHttp:ResponseHead leaks (status strings, too).  
Can't wait to see this land.
rpotss,bbaetz
Need a r on this please
Comment on attachment 70712 [details] [diff] [review]
to plug leak of nsHttpResponseHead resources

r=gagan
Attachment #70712 - Flags: review+
Target Milestone: mozilla1.0 → mozilla0.9.9
a=asa (on behalf of drivers) for checkin to 0.9.9
Keywords: mozilla0.9.9+
Fixed with checkin 
D:\mozilla\netwerk\protocol\http\src>cvs commit nsHttpResponseHead.h
Checking in nsHttpResponseHead.h;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpResponseHead.h,v  <--  nsHttpRe
sponseHead.h
new revision: 1.15; previous revision: 1.14
done
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified fixed (thanks, again).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: