Webkit build 36247 hangs, then crashes when visiting http://politiken.dk . To reproduce: 0. go to http://politiken.dk 1. Wait till the progress bar in the URI field is around 80% 2. The browser now becomes unresponsive and after a while the cursor turns into a beach ball. 3. After a while it crashes in this thread: Thread 0 Crashed: 0 libSystem.B.dylib 0x9718eb9e __kill + 10 1 libSystem.B.dylib 0x97205ec2 raise + 26 2 libSystem.B.dylib 0x9721547f abort + 73 Crash report and sample output attached. The crash may happen around the time when ads are document.writ'ten into the doc, so result may vary based on ads served.
Created attachment 23248 [details] Crash log
Created attachment 23249 [details] Sample output
I can confirm this, with the same crash log. It doesn't occur in Safari 3.1.2, so is a regression, despite the crash itself being in libSystem.
Regressed between r36135 (good) and r36244 (bad), which is a fairly large range of commits, including (as the final commit in the range) the squirrelfish-extreme merge. I don't have privileges to change the title of the bug to reflect this.
Created attachment 23256 [details] partial reduction - will crash eventually Still relies on external resources. Key part is: <div id="tw_toplist_widget"> </div> removing that removes the hang and crash.
Created attachment 23264 [details] better reduction Still relies on one external (horribly obfuscated) javascript file
Created attachment 23265 [details] sample more instructive sample when opening latest reduction. Lots of invalid frame pointer errors - the problem may be in javascript regexes, but I'm not sure, and not expert enough to further reduce the javascript.
Created attachment 23267 [details] Self-contained test case Great work on the reduction - let me just turn it into a self-contained one, by copying the contents of the external JS file into a <script>-tag and deleting the old tag with the href. This one crashes for me, after beachballing and rendering the whole OS unresponsive for several seconds.
For anyone concerned with copyright out there, let me just add that I have informed twingly.com, and asked them to let me know if they can't accept it.
Created attachment 23269 [details] Even more reduced file, that does NOT crash One last interesting tidbit: If you remove the html,head, and body tags in the last test case, you don't get beachballs, nor crashes. See test3_no_body.html
I can confirm this, and I will assign it to myself. Given that the bulk of this range of revisions is the squirrelfish-extreme merge, this is probably due to squirrelfish-extreme.
The crash is due to a memory allocation failing, in which case we call abort. This hang and crash does not occur with WREC disabled, so this is definitely a regression due to SquirrelFish Extreme.
With WREC enabled, it keeps on trying to match the regexp /\b\w+\b/ against the same long string of obfuscated JavaScript. I'll try to reduce it.
<rdar://problem/6205787>
Created attachment 23287 [details] Reduction So, it turns out that the matching of the JS file works fine, it just took so long that with printf debugging I thought that it was hanging there. The problem is with the unpacked code itself. Here's a reduction containing that code. I'll try to reduce it further from here.
Created attachment 23288 [details] Further reduction Here's the problem: print("PASS".replace(/\u00E5/ig, "%C3%A5")); It replaces every character with the string. If I remove the 'i' (for case insensitivity), it works fine. This should be an easy fix. It was hanging the browser because it does a number of these URL escaping substitutions in a row, and since the escaped version is quite a bit larger than a single character, the string size grows exponentially and causes a crash.
Created attachment 23289 [details] Proposed patch
Comment on attachment 23289 [details] Proposed patch r=me
Landed in r36288.