13478 - MLK: File channel or protocol handler?

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Bruce Mitchener]

This was from a September 7, 1999 build on NT.

[W] MLK: Memory leak of 20 bytes from 1 block allocated in
nsAutoMonitor::NewMonitor(char const*)
        Distribution of leaked blocks
                20 bytes from 1 block of 20 bytes (0x070116f8) allocation number
106131
        Allocation location
            new(UINT)      [new.cpp:23]
            nsAutoMonitor::NewMonitor(char const*) [nsAutoLock.cpp:143]
            nsFileChannel::Init(nsFileProtocolHandler *,char const*,nsIURI
*,nsILoadGroup *,nsIEventSinkGetter *) [nsFileChannel.cpp:110]
            nsFileProtocolHandler::NewChannel(char const*,nsIURI *,nsILoadGroup
*,nsIEventSinkGetter *,nsIChannel * *) [nsFileProtocolHandler.cpp:162]
            nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup
*,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:229]
            nsIOService::NewChannel(char const*,char const*,nsIURI
*,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:247]
            nsResourceProtocolHandler::NewChannel(char const*,nsIURI
*,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *)
[nsResourceProtocolHandler.cpp:321]
            nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup
*,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:229]
            nsChromeProtocolHandler::NewChannel(char const*,nsIURI
*,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *)
[nsChromeProtocolHandler.cpp:176]
            nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup
*,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:229]
            NS_OpenURI(nsIChannel * *,nsIURI *,nsILoadGroup *,nsIEventSinkGetter
*) [nsNeckoUtil.cpp:63]
            nsUnicharStreamLoader::nsUnicharStreamLoader(nsIURI *,nsILoadGroup
*,(*)(nsIUnicharStreamLoader *,nsString&,void *,UINT),void *,UINT *)
[nsNetStreamLoader.cpp:80]
            NS_NewUnicharStreamLoader(nsIUnicharStreamLoader * *,nsIURI
*,nsILoadGroup *,(*)(nsIUnicharStreamLoader *,nsString&,void *,UINT),void *)
[nsNetStreamLoader.cpp:211]
            XULContentSinkImpl::OpenScript(nsIParserNode const&)
[nsXULContentSink.cpp:1605]
            XULContentSinkImpl::OpenTag(nsIParserNode const&)
[nsXULContentSink.cpp:1417]

Comment 1

[Warren Harris]

Maybe the XULContentSinkImpl isn't releasing the nsIUnicharStreamLoader here.

Comment 2

[Warren Harris]

This is brendan's.

Comment 3

[brendan-obsolete]

Bruce, what's the good word with that patch I gave you (attached)?

/be

Comment 4

[brendan-obsolete]

Attachment: free deadlock detection stuff

Comment 5

[Bruce Mitchener]

running with that patch drops the leak count on viewer to about 1300 bytes for
startup/load test 0/shutdown from roughly 2000 bytes.

Comment 6

[Bruce Mitchener]

(that was all of the instances of this leak btw)

Comment 7

[brendan-obsolete]

Fix checked in.  Verify via purify on your own, or from bruce's logs.

/be

Comment 8

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0928eda9be96
[fenix] for https://github.com/mozilla-mobile/fenix/issues/13478, letting go of the fragment resource inside onDestroyView of AddonsManagementFragment to avoid memory leak