Last Comment Bug 706932 - crash nsHtml5OwningUTF16Buffer::
: crash nsHtml5OwningUTF16Buffer::
Status: VERIFIED FIXED
: crash
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: x86_64 All
: -- critical (vote)
: mozilla11
Assigned To: Mats Palmgren (vacation)
:
Mentors:
: 666281 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-01 12:23 PST by alex_mayorga
Modified: 2012-03-14 07:25 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (1.13 KB, patch)
2011-12-03 10:13 PST, Mats Palmgren (vacation)
hsivonen: review+
Details | Diff | Splinter Review

Description alex_mayorga 2011-12-01 12:23:51 PST
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.

STR:

- 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..."

RESULT

"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.

Script: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/:206"

Crashes:
 bp-1b1442a9-00ed-4a24-bdd4-c615f2111201
 bp-1e51896e-155e-4bf6-b689-9a4ea2111201

Might be of interest, on the restored session after the crash the URL for the site looks like this:

wyciwyg://0/http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/
Comment 1 Boris Zbarsky [:bz] 2011-12-01 12:28:54 PST
Hmm.  Crash is a stack overflow, and document.write is involved...  Henri, is this actually a parser issue, or something else?
Comment 2 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-12-02 06:00:03 PST
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.
Comment 3 Mats Palmgren (vacation) 2011-12-03 10:12:17 PST
I can reproduce this in a Linux64 debug build when I set 'ulimit -s 1024'.
Comment 4 Mats Palmgren (vacation) 2011-12-03 10:13:11 PST
Created attachment 578847 [details] [diff] [review]
fix
Comment 5 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-12-11 04:47:35 PST
*** Bug 666281 has been marked as a duplicate of this bug. ***
Comment 7 Matt Brubeck (:mbrubeck) 2011-12-18 15:32:25 PST
https://hg.mozilla.org/mozilla-central/rev/e72b86326124
Comment 8 alex_mayorga 2012-03-09 14:41:23 PST
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 =)
Comment 9 alex_mayorga 2012-03-13 07:53:42 PDT
Talked to soon?

Just crashed again with a little more informative crash signature, see bp-fd2b38ae-5600-4371-9770-ce6d22120313
Comment 10 Mats Palmgren (vacation) 2012-03-13 08:14:33 PDT
Alex, that crash report looks like an unrelated problem, please file a new bug.
Comment 11 alex_mayorga 2012-03-14 07:25:44 PDT
(In reply to Mats Palmgren [:mats] from comment #10)
> Alex, that crash report looks like an unrelated problem, please file a new
> bug.

Filed bug 735257 in case it is of interest.

Note You need to log in before you can comment on or make changes to this bug.