Closed Bug 12506 Opened 25 years ago Closed 25 years ago

[MLK] Huge memory leakage on pages with animated GIFs

Categories

(Core :: Networking, defect, P2)

All
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: rpotts)

References

Details

Current builds are leaking large amounts of memory; sitting on www.abcnews.com
for 2 minutes will leak around 80Mb. This leakage seems to be worse on pages
with animated GIFs.
I believe this is a duplicate of 6409, but am leaving open so that sfraser or
pnunn can decide for themselves.
I believe this leak is more serious than 6409, and has got worse in the last few
days.
Assignee: pnunn → warren
Component: ImageLib → Necko
Change component to necko, reassign to warren.
Priority: P3 → P2
Hardware: Macintosh → All
This leakage appears to be coming from nsBuffer::PushWriteSegment(), which
is called from nsSocketTransport code. We are allocating chunks about 500K in
size, which for some reason never get deleted.
#define MAX_IO_BUFFER_SIZE   (1024*1024)//8192

that's a whole megabyte. Is that right?
We appear to be leaking nsHTTPChannels, which in turn leaks nsHTTPRequests,
and their associated buffers.
Status: NEW → ASSIGNED
I'm working on this now.
http://www.cybersight.com/~bruce/apprunner.mongo.19990827.log

might contain some useful purify data.
Target Milestone: M10
Blocks: 12838
There are rumors that gagan fixed at least part of this, so I'm cc:ing him.
I just checked in a change to reduce the buffer size. Now the socket transport
should allocate up to 64k in 4k chunks before deciding to suspend the request.
I don't know if those are the right numbers, but they're better than the 1Mb
that we had before.

But that just makes the leak smaller. I haven't looked into why we're leaking
here.
Severity: normal → critical
I was told that the ownership issues in here were going to be fixed by rpotts
once he returned from vacation?  Is this true?  Right now, this is dragging down
a lot of data and obscuring real results in Purify.

What's the status?
Assignee: warren → rpotts
Status: ASSIGNED → NEW
I'm guessing the following two lines of the log are the culprit:

        NS_OpenURI(nsIChannel**,nsIURI*) [nsNeckoUtil.cpp:62]
        nsDocumentBindInfo::Bind(nsIURI*,nsIStreamListener*,nsIInputStream*)
[nsDocLoader.cpp:1675]

I suspect that the document bind info is caching the channel, but it's
destructor isn't releasing it.

Assigning to Rick.
Blocks: 13283
vidur indicates on #mozilla that there is a circular dependency between the
docloader and the loadgroup, and that forces the webshell to leak.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
We are no longer leaking channels.  This should have been fixed when the M9
branch landed.

I went to www.abcnews.com and stayed there for a while and didn't see any large
memory leakage...

The fact that WebShells are not being deleted is *not* related to this bug since
the webshell is not destroyed when new pages are loaded...  I believe that vidur
is looking into the webshell leaks.

Let me know if you are still seeing channel leakage.

-- rick
Okay, then I will dig up specific Necko leaks and begin filing bugs on each of
them.
Status: RESOLVED → VERIFIED
Apprunner running approximately 2 minutes on Win NT leaked about 100K.

100K != 80 MB, so marking as verified.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
The problem is still in the very last firefox release (but not in mozilla suite) try http://facs.scripps.edu/surf/images/euranim.gif
REOPEN
You need to log in before you can comment on or make changes to this bug.