Last Comment Bug 706932 - crash nsHtml5OwningUTF16Buffer::
: crash nsHtml5OwningUTF16Buffer::
: crash
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: x86_64 All
: -- critical (vote)
: mozilla11
Assigned To: Mats Palmgren (:mats)
: Andrew Overholt [:overholt]
: 666281 (view as bug list)
Depends on:
  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: ---

fix (1.13 KB, patch)
2011-12-03 10:13 PST, Mats Palmgren (:mats)
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.


- Load

- Let Script: 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:

Comment 1 Boris Zbarsky [:bz] (still a bit busy) 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) 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 (:mats) 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 (:mats) 2011-12-03 10:13:11 PST
Created attachment 578847 [details] [diff] [review]
Comment 5 Henri Sivonen (:hsivonen) 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
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 (:mats) 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.