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 User image 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 User image 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 User image 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 User image 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 User image Mats Palmgren (:mats) 2011-12-03 10:13:11 PST
Created attachment 578847 [details] [diff] [review]
Comment 5 User image Henri Sivonen (:hsivonen) 2011-12-11 04:47:35 PST
*** Bug 666281 has been marked as a duplicate of this bug. ***
Comment 7 User image Matt Brubeck (:mbrubeck) 2011-12-18 15:32:25 PST
Comment 8 User image 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 User image 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 User image 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 User image 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.