CRASH!

Browsers try their best to handle the arbitrary content on the web, but can crash for a variety of reasons; memory leaks, infinite loops… it’s a tough world online.

Sometimes they fail. This article dissects a few Javascript snippets that exploit these factors to give that gruesome kill screen.

Chrome

for(var i = 0; i < 1000000; i++){
history.pushState(null,'','');
}

This snippet will freeze Chrome completely after a few seconds. The built-in Chrome task manager will not work and the only way to escape is to kill the browser altogether.

Like all other major browsers, Chrome uses separate threads to handle resource requests and user interaction. This allows you to continue to click buttons and navigate pages without having to wait for any blocking Javascript to finish executing. Without this, any long loops would freeze the browser.

Occasionally though, threads must communicate with each other via IPCs (Interprocess Communications) that block both threads. One way to initiate an IPC is to push a URL to the browser history. Do it a million times, and the thread handling UI is guaranteed to be frozen.

Although the Chromium community isn’t sure how to fix it, limiting the number of IPCs that can be started by a script is a potential solution. Opera and Safari will also crash from this.

Firefox

window.location = "data:text/html,<script>location+=location+'A'.repeat(100000000)</script>"

This script will make Firefox unresponsive and replace your cursor with an endless beachball of death.

At first the issue seems to be the giant string generated by .repeat, but Firefox handles the error created by this single too-large string (called an Out-Of-Memory error) gracefully.

The issue arises from the security feature where changing the window’s location (the URL in the top bar), causes the browser to reload. This prevents sites from spoofing their domain. For example:

window.location = "www.google.com"

changes the URL in the address bar to “www.google.com” and promptly reloads, sending you to the real Google. In the crash snippet, the browser is redirected to another copy of the script with a million “A”s appended to it.

That long string causes an OOM error, but not before the script is executed again. And again. And again. There doesn’t appear to be any limits on how large the script can get, so Firefox gives up.

Internet Explorer

Microsoft gave up a long time ago on older versions of IE, and you should too. Javascript isn’t even required to crash IE 9 and below.

<html>
<head>
<style type="text/css">
#a {
margin:0 10px 10px;
}
#b {
width:100%;
}
</style>
  <title>IE Crasher</title>
</head>
<body>
<table>
<tr>
<td>
<div id=”a”>
<form id=”b”>
<input type=”text” name=”test”/>
<!-- Notice the unclosed form tag -->
</div>
</td>
<td width=”1″></td>
</tr>
</table>
</body>
</html>

The Broken Phonograph

A general principle of programming is that a well-designed system should be able to handle any and all inputs it may encounter. However, as the range of inputs to browsers becomes increasingly vast and complex, this may become an impossible task.

This is similar to a short story by Douglas Hofstadter in which a man purchases a record player that can produce any possible sound, only to have his devious friend create a sound that would destroy it.

I sent off to the manufacturers for a description of its design. After receiving that by return mail, I analyzed the entire
construction of the phonograph and discovered a certain set of sounds which, if they were produced anywhere in the vicinity, would set the device to shaking and eventually to falling apart.

All of these scripts are annoying, but completely harmless.

Credit for discovering these scripts goes to Matt Bryant and crashie8.com