This problem also happens on Linux, trunk and 092 branch. I'll open a bug. I'm working on a fix, now.
Later, --Aaron aaron reed wrote: > Hey, > > I work on the OS/2 port and we are working on a product based off of > mozilla_0_9_2_branch. We are running into a timing problem with a > stress testcase. We basically have 7 or 8 pages looped together via a > refresh meta tag that will load a page every 5 seconds in order (1, 2, > 3, ..., 8, 1, 2 ...). Over time we are having a memory leak and I > noticed a lot of nsParser objects sitting around, which are keeping > nsHTMLDocuments, CNavDTDs, and HTMLContentSinks alive. I've noticed > that nsParser::OnStopRequest will get called, but the parser object > isn't complete (mPendingContinueEvent flag is set). So this event will > get posted over and over in the bad case. Eventually, > nsParser::CancelParsingEvents will get called when the next refresh > timer fires and tells the current doc loader to cleanup and get out of > Dodge. > > CancelParsingEvents will keep the parser from going through the normal > course of things, so it will never get the NS_RELEASE( mParser). It > looks like normally DidBuildModel (when IsComplete() is TRUE) will bring > the refcount down to 1 and then that last reference would get removed by > the NS_RELEASE(mParser) in nsParserContinueEvent::HandleEvent. I don't > see where CancelParsingEvents takes into account releasing the > references that are on the parser. > > So is this a bug? Or is the bug the fact that we still have pending > events when the refresh timer hits? On Windows we don't have this > problem because CancelParsingEvents is never called. On the trunk on > OS/2, we don't leak nearly as often, but if the browser is kept busy > enough, it will happen a little bit. > > Any help would be appreciated. > > Thanks, > --Aaron > [EMAIL PROTECTED]
