162959 - ftp somehow leaks the category manager

Status: RESOLVED WORKSFORME

(Core Graveyard :: Networking: FTP, defect, P2)

Description

[Alec Flett]

one of the big leaks on tinderbox seems to be related to FTP and the category
manager - we're leaking the entire category manager and all of its categories,
strings, you name it.. from my initial testing, it only seems to happen when
someone uses FTP once.. if you don't use FTP it doesn't seem to leak. I don't
claim to understand it yet, but I wanted the bug filed :)

(this is among other FTP leaks that I haven't yet narrowed down)

Comment 1

[Alec Flett]

ok, just one more comment with respect to this - I don't see any reason why FTP
of all things should be making it leak - I mean, it doesn't even seem to USE the
category manager. So there's something else funny going on. it could be the
thing that converts the ftp directory listing to HTML.. anyone know where that
is/how it works?

Comment 2

[Bradley Baetz (:bbaetz)]

alecf: netwerk/streamconv/converters/{nsFTPDirListingConv.cpp,
nsIndexedToHTML.cpp} has the ftp->intermediate->html format

Comment 3

[Alec Flett]

ok, this is particularly strange, because nothing in the entire netwerk/
directory seems to hold a long-lived reference to the category manager.

Comment 4

[Bradley Baetz (:bbaetz)]

Maybe we're holding onto somthing which is? Can't the refcount balancer thingy
find out who that is?

Comment 5

[Bradley Baetz (:bbaetz)]

*** Bug 163195 has been marked as a duplicate of this bug. ***

Comment 6

[benc]

Just so I understand:

bug 160465 fixed the problem w/ the build system, but we still have some kind of
problem w/ the ftp code...?

Comment 7

[Alec Flett]

no, bug 160465 exposed the FTP problem.. we didn't know it existed until that
bug was "fixed"

ok, and nsDSURIContentListener seems to be the only relevant object that's
holding a long-term reference to the category manager.. my purify build has
started behaving badly, so I'm stuck on this until the planets realign

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

Is this relevant?

[E] ABR: Array bounds read in nsDependentCString::Rebind(char const*,char 
const*) {2 occurrences}
        Reading 1 byte from 0x0a8b5dcc (1 byte at 0x0a8b5dcc illegal)
        Address 0x0a8b5dcc is 1 byte past the end of a 924 byte block at 
0x0a8b5a30
        Address 0x0a8b5dcc points to a malloc'd block in heap 0x02770000
        Thread ID: 0x71c
        Error location
            nsDependentCString::Rebind(char const*,char const*) 
[nsDependentString.h:160]
            nsDependentCString::Rebind(char const*,UINT) 
[nsDependentString.h:169]
            nsDependentCString::nsDependentCString(char const*,UINT) 
[nsDependentString.h:173]
            nsIndexedToHTML::FormatInputStream(nsIRequest *,nsISupports 
*,nsAString const&) [nsIndexedToHTML.cpp:413]
            nsIndexedToHTML::OnStartRequest(nsIRequest *,nsISupports *) 
[nsIndexedToHTML.cpp:333]
            nsFTPDirListingConv::OnStartRequest(nsIRequest *,nsISupports *) 
[nsFTPDirListingConv.cpp:330]
            nsStreamListenerTee::OnStartRequest(nsIRequest *,nsISupports *) 
[nsStreamListenerTee.cpp:50]
            DataRequestForwarder::DelayedOnStartRequest(nsIRequest 
*,nsISupports *) [nsFtpConnectionThread.cpp:282]
            DataRequestForwarder::OnDataAvailable(nsIRequest *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsFtpConnectionThread.cpp:359]
            nsOnDataAvailableEvent::HandleEvent(void) 
[nsStreamListenerProxy.cpp:194]
        Allocation location
            malloc         [dbgheap.c:129]
            PR_Malloc      [prmem.c:474]
            nsMemoryImpl::Alloc(UINT) [nsMemoryImpl.cpp:320]
            nsMemory::Alloc(UINT) [nsMemory.cpp:75]
            nsIndexedToHTML::FormatInputStream(nsIRequest *,nsISupports 
*,nsAString const&) [nsIndexedToHTML.cpp:388]
            nsIndexedToHTML::OnStartRequest(nsIRequest *,nsISupports *) 
[nsIndexedToHTML.cpp:333]
            nsFTPDirListingConv::OnStartRequest(nsIRequest *,nsISupports *) 
[nsFTPDirListingConv.cpp:330]
            nsStreamListenerTee::OnStartRequest(nsIRequest *,nsISupports *) 
[nsStreamListenerTee.cpp:50]
            DataRequestForwarder::DelayedOnStartRequest(nsIRequest 
*,nsISupports *) [nsFtpConnectionThread.cpp:282]
            DataRequestForwarder::OnDataAvailable(nsIRequest *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsFtpConnectionThread.cpp:359]

Comment 9

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Purify output on 'relevant' FTP stacks

This is just a listing of pretty much all stacks with 'FTP' in their name, as
outputted by Purify - some of them are obviously out of the scope of this bug
(for instance, I think Gordon should own the cache leak), but maybe they're all
related, I'm not sure.

Comment 10

[Alec Flett]

nah - interesting and should be fixed, but nothing that would cause a leak

Comment 11

[Bradley Baetz (:bbaetz)]

stephend: Thats separate - I filed bug 164197, thanks

The other ones in teh attachment aren't ftp related.

Comment 12

[Alec Flett]

These bugs missed the 1.2 train. Moving these out to 1.3alpha

Comment 13

[Alec Flett]

bumping these to 1.5alpha, I just don't have time in 1.4beta...