I can make Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111201 Firefox/11.0a1 ID:20111201031025 crash on queue.
- Load http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/
- Let Script: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/:206 continue
- Click "Back" button when the page is forever "Connecting..."
"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Might be of interest, on the restored session after the crash the URL for the site looks like this:
Hmm. Crash is a stack overflow, and document.write is involved... Henri, is this actually a parser issue, or something else?
If the crash reason is correct, this must be a case of the linked list of buffers having grown so long that when nsRefPtr recursively destroys the whole linked list, the stack grows too much. I guess this could be avoided by having an explicit loop for destroying the linked list instead of letting the nsRefPtr destructor recurse over it.
I can reproduce this in a Linux64 debug build when I set 'ulimit -s 1024'.
Created attachment 578847 [details] [diff] [review]
*** Bug 666281 has been marked as a duplicate of this bug. ***
On Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120309 Firefox/13.0a1 ID:20120309062528 I can't reproduce the crash with STRs on the initial report.
Kudos to all Matts involved =)
Talked to soon?
Just crashed again with a little more informative crash signature, see bp-fd2b38ae-5600-4371-9770-ce6d22120313
Alex, that crash report looks like an unrelated problem, please file a new bug.
(In reply to Mats Palmgren [:mats] from comment #10)
> Alex, that crash report looks like an unrelated problem, please file a new
Filed bug 735257 in case it is of interest.