User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050125 Firefox/1.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050125 Firefox/1.0+ I'v found libcgi.sf.net to crash my browser. Stripping down the site focused my attention to code, which tries to hang Firefox: <html></html Closing '>' character ich missing. Subtags or any other content of <html> does not have any matter. Reproducible: Always Steps to Reproduce: 1. Go to libcgi.sf.net website Actual Results: Firefox crashed.
Can you post Talkback ID "firefox/components/talkback/talkback" or a GDB stacktrace if you built Firefox yourself for this crash ? Firefox 1.0 on WinXP doesn't crash but doesn't show the source right: </html></<html> instead of </html perhaps because of bug 57717. Use http://web-sniffer.net/ to see the real HTML sent.
different behavior on my mozilla 1.8a6 nightly build 2005011906 Win XP: while loading that url the browser hangs, nothing is being displayed, and there's no way to restore the control on mozilla but it doesn't crash. Task manager says the application is not responding and the cpu usage is at 99% (but memory usage is not growing). There's nothing that can be done other than to manually kill the mozilla process.
(In reply to comment #2) > different behavior on my mozilla 1.8a6 ops, i mean 1.8b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050119
Created attachment 172622 [details] Testcase The testcase just consists of: <html> </html and that makes my 2004-01-27 trunk build become unresponsive taking 100% cpu.
The bug does not occur in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 Firefox/1.0+ But the bug does occur in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050116 Firefox/1.0+ My guess is this is a regression from the fix for bug 274786.
Taking. I'll attach a patch in a couple of hours (I know what's causing this).
Created attachment 172635 [details] [diff] [review] patch v1 I missed an early return, so we were not adding the second token (and returning kEOF from ConsumeEndTag). This meant that when my last-ditch attempt to consume all content took effect, we were calling CTextToken::Consume() with the scanner already at the end of the document, the first thing that CTextToken::Consume() does is to set the position to one past the current, causing bad things to happen. I've added an assert to catch related problems (which shouldn't exist).
Tweaking summary and keywords to reflect that this is a *hang*, not a crash. (I've also removed stackwanted since I know what's happening).
*** Bug 280564 has been marked as a duplicate of this bug. ***
Comment on attachment 172635 [details] [diff] [review] patch v1 r+sr=jst
Fix checked in. Sorry for the inconvenience!
*** Bug 280690 has been marked as a duplicate of this bug. ***
The testcase https://bugzilla.mozilla.org/attachment.cgi?id=172622 now works fine for me with build 2005-02-01-06 using Seamonkey trunk on Windows XP. Verified FIXED.