299704 - Mozilla freezes and leaks memory setting ftp image source via JS

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, defect)

Description

[Andrew Schultz]

This is an FTP version of bug 228233.  Current trunk builds (suite) exhibit
uncontrolled memory growth (~1MB/s) setting an image source via JS to an FTP
URL.  I'll attach a testcase.  Unfortunately, XPCOM_MEM_LEAK_LOG does not show
any substantial leak (a few hundred bytes from random objects).  valgrind shows
more leaked, but only a few KB that could be related to this bug. I also don't
think the real leak happens running under valgrind (probably too slow).  I get a
zillion of these after I hit "stop script", but only if I run under valgrind:

###!!! ASSERTION: ftp state is null.: 'Error', file
/build/andrew/moz-debug/mozilla/netwerk/protocol/ftp/src/nsFTPChannel.cpp, line 545

Comment 1

[Andrew Schultz]

Attachment: testcase

loading this testcase grabs 1+MB/s for me with trunk suite build 2005070405

Comment 2

[Boris Zbarsky [:bzbarsky]]

Andrew, is that the right testcase?  It doesn't have an image or ftp:// urls in it...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Andrew, please see comment 2?

Comment 4

[Andrew Schultz]

Attachment: the real testcase

right.  here's the real testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmmm... So unlike bug 228233 there's no actual leak?  Just memory growth while the testcase runs (because the channels involved can't get deallocated until the event queue gets processed and the testcase is not allowing event processing)?

Comment 6

[Andrew Schultz]

Well, no leak that XPCOM_MEM_LEAK notices.  And running under valgrind seems to avoid this bug in the first place.  But I don't see memory reclaimed after I stop the script and open / close windows to trigger garbage collection.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, ok.   That I should look into.  Thanks!

Comment 8

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I assume this is still a problem, right?

Comment 10

[Andrew Schultz]

Yes.  The slow script warning seems to help in stopping the memory growth (I still leak sometimes), but I increased the timeout to 60s and I grew from 275MB virtual to 750MB.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So I tried running with XPCOM_MEM_LEAK_LOG and calling nsTraceRefcntImpl::DumpStatistics(0, 0) after closing the testcase and triggering a GC.  The only FTP object alive at that point is the ftp protocol handler.

I wonder whether this is basically a fragmentation issue.  stuart, is there a difference here between our normal allocators and jemalloc?

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to comment #11)
>  stuart, is there a difference here between our normal allocators and jemalloc?

Comment 13

[Patrick McManus [:mcmanus]]

actually, take the http bug but close ftp as deprecated