COMMAND
recursive frames and frames
SYSTEMS AFFECTED
IE 4.x, Netscape 3.x, 4.x on all platforms
PROBLEM
Lloyd Vancil found following way to crach your browser. Here's a
code:
---test.html---
<HTML>
<HEAD>
<TITLE>IE 4 BUG</TITLE>
</HEAD>
<FRAMESET ROWS = 50%,50%>
<FRAME SRC = "test.htm">
<FRAME SRC = "test.htm">
</FRAMESET>
<BODY>
</BODY>
</HTML>
---test.html---
On IE it seems that the loop is not necessary. Name the page
ie4test.html and leave the frame links as test.htm (which need
not exist), and it still crashes IE4 (info by Phil V. Stracchino).
What happens here is that there is a loop. test.htm creates a page
with two frames, the source for these two frames is test.htm which
create another two frames, and so on and so on.
Here is a info from one test. It was tested on a Dell Latitude
XPI P133 ST with 40MB RAM. The laptop is running Windows NT
Workstation build 1381 with service pack 3 applied. No hotfixes.
The browser tested with was Internet Explorer 4.0. This is what
happens when you load the test.htm page into IE 4.0 (test
performed by Rommetveit Per Stuve):
The CPU Usage bar in Windows NT Task Manager goes to 100%
The MEM Usage bar increases very fast
The Internet Explorer 4.0 application is reported as not
responding
The only way to end IE 4.0 is to end it with the help of Task
Manager and kill the application or the process, or use kill via
the command line. The CPU Usage stays put around 80 to 100% for
1 minute, then it goes up and down. T he MEM Usage increases all
the time. Then CPU Usage goes stable on 15-25% for a long while.
After 37 minutes and a lot of disk trashing you get a message box
saying:
System Process - Out of Virtual Memory
Your system is running low on virtual memory. Please close
some applications. You can then start the System option in the
Control Panel and choose the Virtual Memory button to create
an additional paging file or to increase the size of your
current paging file.
Commit Charge dropped from 133 784K to 46 528K when IE 4.0 ended.
Note that it may not crash every time but it does so very
consistently. It crashed when you load some page after the page
containing the recursive frames. If the page you load after is
already in you cache your chances of crashing seem to be greater.
SOLUTION
This bug might turn out to be un-fixable - it's known as the
halting problem in computer science circles - it's not possible
to tell whether a given program will ever terminate, so you can't
ever catch all possible recursive nastiness that can be put into a
web page.