From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020708 BuildID: 2002070813 If I go to http://www.artistcollaboration.com/discus/messages/316/316.html?1026164385 (or alternatively, http://www.artistcollaboration.com/discus/ and then click on Collaboration Station), Mozilla will start to display the page, but at some point CPU usage will jump to 100%, memory usage will climb and climb, and Mozilla will eventually crash after a few minutes of Windows thrashing trying to allocate more and more memory. This is with the latest build on the FTP site, 2002070813. Reproducible: Always Talkback ID TB8117775E.

no crash (yet) with linux build 20020708. it's up to 650 MB and still growing (I have lots of RAM+swap) the page has 4218 <p><font size=1>, then text, then 4218 </font></p> shouldn't the patch in bug 18480 catch this? marking NEW ==> parser

I am beginning to hate bug 150955 marking NEW for real

Because mozilla use tree struct to parse the html tag. the too many tag <p> cause the the tree too deep and lead to the recursive call take too much stack space, finally, mozilla produce stack overflow. I think mozilla is short of a mechanis for avoid stack overflow, I suggest to add it in some recursive call.

The endless loop call for the next 4 function caused the stack overflow. nsCSSFrameConstructor::ConstructFrame nsCSSFrameConstructor::ConstructFrameInternal nsCSSFrameConstructor::ConstructFameByDisplayType nsCSSFrameConstructor::ConstructInline nsCSSFrameConstructor::PressInlineChildren nsCSSFrameConstructor::ConstructFrame ... .... The mozilla finally caused stack overflow in order to parse the too many tag <p>.

This is a known issue. Please refer to bug 56182.

URL is dead.

See also bug 22480 *** This bug has been marked as a duplicate of 56182 ***