Pulls from over the weekend and March 15, 1999. MLK: 40 bytes leaked at 0x588318 * This memory was allocated from: malloc [rtlib.o] __bUiLtIn_nEw [libgcc.a] __builtin_new [rtlib.o] NS_NewWellFormed_DTD(nsIDTD**) [nsWellFormedDTD.cpp:103] CSharedParserObjects::CSharedParserObjects() [nsParser.cpp:93] nsParser::nsParser(nsITokenObserver*) [nsParser.cpp:149] nsParserFactory::CreateInstance(nsISupports*,const nsID&,void**) [nsParserFactory.cpp:124] nsComponentManagerImpl::CreateInstance(const nsID&,nsISupports*,const nsID&,void**) [nsComponentManager.cpp:1123] nsComponentManager::CreateInstance(const nsID&,nsISupports*,const nsID&,void**) [nsRepository.cpp:67] nsHTMLDocument::StartDocumentLoad(nsIURL*,nsIContentViewerContainer*,nsIStreamLi stener**,const char*) [nsHTMLDocument.cpp:340] nsDocFactoryImpl::CreateDefaultDocument(nsIURL*,const char*,nsIContentViewerContainer*,nsIStreamListener**,nsIContentViewer**) [nsDocLoader.cpp:382] nsDocFactoryImpl::CreateInstance(nsIURL*,const char*,const char*,nsIContentViewerContainer*,nsISupports*,nsIStreamListener**,nsIContentView er**) [nsDocLoader.cpp:279] nsDocumentBindInfo::OnStartBinding(nsIURL*,const char*) [nsDocLoader.cpp:1700] NET_NGLayoutConverter [nsStubContext.cpp:763] NET_StreamBuilder [mkstream.c:241] net_setup_file_stream [mkfile.c:783] net_ProcessFile [mkfile.c:1319] NET_ProcessNet [mkgeturl.c:3371] NET_PollSockets [mkselect.c:298] nsNetlibService::NetPollSocketsCallback(nsITimer*,void*) [nsNetService.cpp:1217] TimerImpl::FireTimeout() [nsTimer.cpp:73] nsTimerExpired [nsTimer.cpp:189] g_timeout_dispatch [gmain.c:1147] g_main_dispatch [gmain.c:647] g_main_iterate [gmain.c:854] g_main_run [gmain.c:912] gtk_main [gtkmain.c:475] nsAppShell::Run() [nsAppShell.cpp:152] nsNativeViewerApp::Run() [nsGTKMain.cpp:42] main [nsGTKMain.cpp:97]

Insure++ thinks this is where the leak is (and looking at the code, is the stuff placed into the mDTDDeque on CSharedParserObject ever freed?): >> *aInstancePtr = (CNavDTD*)(this); Memory leaked due to pointer reassignment: it Lost block : 0x0817ac40 thru 0x0817ac67 (40 bytes, 1 element) it, allocated at: ___builtin_new() NS_NewWellFormed_DTD() nsWellFormedDTD.cpp, 103 CSharedParserObjects::CSharedParserObjects() nsParser.cpp, 93 nsParser::nsParser() nsParser.cpp, 146 nsParserFactory::CreateInstance() nsParserFactory.cpp, 124 nsComponentManagerImpl::CreateInstance() nsComponentManager.cpp, 1079 nsComponentManager::CreateInstance() nsRepository.cpp, 67 XULDocumentImpl::StartDocumentLoad() nsXULDocument.cpp, 987 Stack trace where the error occurred: CNavDTD::QueryInterface() CNavDTD.cpp, 191 NS_NewNavHTMLDTD() CNavDTD.cpp, 218 CSharedParserObjects::CSharedParserObjects() nsParser.cpp, 96 nsParser::nsParser() nsParser.cpp, 146 nsParserFactory::CreateInstance() nsParserFactory.cpp, 124 nsComponentManagerImpl::CreateInstance() nsComponentManager.cpp, 1079 nsComponentManager::CreateInstance() nsRepository.cpp, 67 XULDocumentImpl::StartDocumentLoad() nsXULDocument.cpp, 987 nsDocFactoryImpl::CreateRDFDocument() nsDocLoader.cpp, 486 nsDocFactoryImpl::CreateInstance() nsDocLoader.cpp, 291 nsDocumentBindInfo::OnStartBinding() nsDocLoader.cpp, 1613 NET_NGLayoutConverter() nsStubContext.cpp, 763 NET_StreamBuilder() mkstream.c, 242 net_setup_file_stream() mkfile.c, 783 net_ProcessFile() mkfile.c, 1319 NET_ProcessNet() mkgeturl.c, 3371 NET_PollSockets() mkselect.c, 298 nsNetlibService::NetPollSocketsCallback() nsNetService.cpp, 1217 TimerImpl::FireTimeout() nsTimer.cpp, 73 nsTimerExpired() nsTimer.cpp, 188

We're not leaking in the classic sense here. The DTD's (3) are kept around until the app itself closes, and are cleaned up by the OS. I dont plan to change this, unless someone has a good reason.

We're not leaking in the classic sense here. The DTD's (3) are kept around until the app itself closes, and are cleaned up by the OS. I dont plan to change this, unless someone has a good reason.

Well, aren't we touting Gecko as this embeddable component? If I'm done with my HTML stuff and want to shut the engine down, why shouldn't I get all that data freed?

Marking Verified/Won't Fix.

Shaver's concern hasn't been addressed yet.

I have two problems with this being reopened: 1. Someone should have spoken with me first -- unless shaver is setting policy now. 2. The MLK was fixed many weeks ago. Perhaps someone should have checked?

Nobody thinks I'm setting policy, but apparently nobody thought that the embedding concerns were worthy of a response, either. I'm glad to hear that the leak was fixed, but there was no reason for anyone to believe that the situation had changed if the bug was just left WONTFIX. Was someone going to come and update it?

Verified