Bring up viewer and quit... [W] MLK: Memory leak of 5 bytes from 1 block allocated in PL_strndup Distribution of leaked blocks Allocation location malloc [dbgheap.c:129] PL_strndup [strdup.c:55] nsStdURL::ExtractString(char *,char * *,UINT,UINT) [nsStdURL.cpp:654] nsStdURL::Parse(void) [nsStdURL.cpp:207] nsStdURL::SetSpec(char *) [nsStdURL.cpp:973] nsFileProtocolHandler::NewURI(char const*,nsIURI *,nsIURI * *) [nsFileProtocolHandler.cpp:130] nsIOService::NewURI(char const*,nsIURI *,nsIURI * *) [nsIOService.cpp:200] nsIOService::NewChannel(char const*,char const*,nsIURI *,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:236] nsResourceProtocolHandler::NewChannel(char const*,nsIURI *,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *) [nsResourceProtocolHandler.cpp:321] nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup *,nsIEventSinkGetter *,nsIChannel * *) [nsIOService.cpp:220]

I think seth/andreas already fixed this... have a dup somewhere... Andreas?

The URL is leaking too...

There was an issue with a DupString usage not ExtractString. This one is new.

Seems to have been a bug in shutdown. I'm giving it to warren to see if it still exists in purify.

->m12

Patrick: Does this bug still exist according to your logs? If not, please mark fixed. Thanks.

Yes, it does still exist as a leak in Mozilla. Here's the leaksoup report: 0x04A92308 [1] <void*> (17){17} parents 0x7461736B 0x734F7665 0x726C6179 0x2E637373 0x00000000 malloc PL_strndup nsStdURL::ExtractString(char*, char**, unsigned int) nsStdURL::ParsePath() nsStdURL::Parse() nsStdURL::SetSpec(const char*) nsChromeProtocolHandler::NewURI(const char*, nsIURI*, nsIURI**) nsIOService::NewURI(const char*, nsIURI*, nsIURI**, nsIProtocolHandler**) nsIOService::NewURI(const char*, nsIURI*, nsIURI**) NS_NewURI(nsIURI**, const char*, nsIURI*) NS_NewURI(nsIURI**, const nsString&, nsIURI*) XULContentSinkImpl::ProcessStyleLink(nsIContent*, const nsString&, int, const nsString&, const nsString&, const nsString&) XULContentSinkImpl::AddProcessingInstruction(const nsIParserNode&) CWellFormedDTD::HandleProcessingInstructionToken(CToken*) CWellFormedDTD::HandleToken(CToken*, nsIParser*) CWellFormedDTD::BuildModel(nsIParser*, nsITokenizer*, nsITokenObserver*, nsIContentSink*) nsParser::BuildModel() nsParser::ResumeParse(nsIDTD*, int) nsParser::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsChannelListener::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsFileChannel::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) nsOnDataAvailableEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent(PLEvent*) PL_HandleEvent PL_ProcessPendingEvents nsEventQueueImpl::ProcessPendingEvents() nsEventQueueServiceImpl::ProcessEvents() nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&) Repeater::DoRepeaters(const EventRecord&) nsMacMessagePump::DispatchEvent(int, EventRecord*) Leak Parents: 0x04BE7654 [1] <nsStdURL> (60){228}

As you can see this, leak is caused by a leaking nsStdURL, which is held by a CSSStyleSheetInner by my reckoning. Here the ownership gets murky, as I don't see a clear leak root (due to reference cycles).

Patrick/Nisheeth: Do we already have a bug on this CSS leak? If so, there's no point in keeping this one. If not, we should rename and reassign.

Pierre, the new owner of the style system, should probably investigate this further because a CSS leak is involved. Re-assigning this to him.

CSSStyleSheetImpl::Init() does a suspicious NS_ADDREF(mInner->mURL). CSSStyleSheetImpl::GetURL() should be checked too.

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

Block-moved memory leaks to attinasi

The AddRef in CSSStyleSheetImpl::Init()is correct. It would be better if the inner took care of itself in this regard, however it is doing the AddRef in the case where the the URL is initialized in the inner's ctor, so when the outer sets it it must be addref'd. (The case where Init is replacing the inner's url could represent a leak, however the DEBUG build would assert if that happened.) The GetURL method is doing an AddRef, and all callers I found do their part and release it. Unless the StyleSheet is being leaked, this looks clean. I'll check purify and recent leak logs but I suspect this is fixed.

=> TK @ AOL

=> me

This bug now looks invalid. nsStdURL has completely changed, and no longer has an ExtractString.

per Warren's comments - verifying INVALID