30 comments

[ 2.3 ms ] story [ 73.7 ms ] thread
"What were you expecting...? NoScript detected, changing pwn technique. Please wait."

nty

Well that's just mean.
As a Firefox user I can confirm this does indeed crash Firefox. It however also crashes Chrome to an extent (at least on Windows) you get the aw snap page shortly after it loads.

Seems like it just overloads the browser using this technique in the URL: data:text/html,<script>location+=location+'A'.repeat(100000000);</script> - I haven't tested in any other browser, but to me that technique would crash any browser, probably even worse on mobile.

Hmm, it started using a bunch of CPU and memory, but I kill -9ed it before it actually died by itself.
Seriously, no disclaimer that this will hang Firefox, and will likely lock up a system for 20+ seconds before it will let you kill Firefox (linux)? (Thankfully I run linux in a vmware image, so I can go play a game while waiting for linux to figure out the process went rogue)

I didn't realize HN was the new 4chan/8chan. Sigh.

The title is named crash firefox isn't it?
Yes, it's not named "lock-up the entire system". I was expecting a segfault, quite disappointed.
There was at least one clue provided by the name of the site...
A crash is not a hang. Firefox never crashed, eventually linux asked if I wanted to kill it, but there was no segfault, no crash.
I don't know what you expected.
A big label on the page saying "Not really, FF is rock-solid. Have a nice day HN!"?
I just sshed into my computer from my phone to kill firefox, although I probably could have switched to a VT as well.
I continue to be incredibly sad that any OS considers it ok to lock-up the entire UX for a program running amok. Most people would consider such an OS defective, and consider what else is out there, rather than ssh into it. I can't really fault them, I do wonder what is wrong with people making such systems that think this is an acceptable situation.
When a program aggressively allocates memory, buffers must be flushed back to disk, stuff may need to get moved into swap, etc. I/O bound stuff gets higher priority because... I don't know why... probably the throughput is greater that way, or perhaps it's more urgent. Not sure if there's a solution other than having enough RAM that you are never I/O bound. Perhaps if Linux wasn't so aggressive about caching, it would happen less, but things would be slower overall.
content in case it crashes your browser and you're interested:

    data:text/html,<script>location+=location+'A'.repeat(100000000);</script>
this was posted in 4chin yesterday
Got a crash on Chrome (Linux)
My firefox with noscript did not crash
Hmm, I haven't checked the code yet, but Firefox 37 on Arch with NoScript crashed for me on a reload. I just got the noscript detection the first time.
Ditto.

It did hang for a bit (30s?) when closing the tab, however.

Actually, it didn't crash my firefox 40.0a . It asked me eventually if I would like to stop running scripts on this page. Which I did and I am now typing this using the same Firefox instance. Only it now is using 4.6gb of memory. :)
Try running 'curl' on that URL (NQSFW). You can see what it's doing with the loop majke pointed out.
Hung, but eventually recovered on 37.

Not really sure what I was expecting.

When it detected noscript, it replaced the page with this:

    <meta http-equiv="refresh" content="0">AAAA.........
...as displayed with ^U, except the "AAAA...." wasn't visible until I pasted it in this text box. I'm not sure, but I suspect the length of the AAAAs was growing rapidly. There's a lot of memory and more than one core on this system, so I think I killed the tab, which appeared only as a blank page, before it became too destructive.
It was like knowing the link is a Rickroll and clicking on it anyway...

Did indeed crash Firefox 37.0.1.