The default bug view has changed. See this FAQ.

crash nsHtml5OwningUTF16Buffer::

VERIFIED FIXED in mozilla11

Status

()

Core
HTML: Parser
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: alex_mayorga, Assigned: mats)

Tracking

({crash})

Trunk
mozilla11
x86_64
All
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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/
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.
(Assignee)

Comment 3

5 years ago
I can reproduce this in a Linux64 debug build when I set 'ulimit -s 1024'.
Component: General → HTML: Parser
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → parser
(Assignee)

Comment 4

5 years ago
Created attachment 578847 [details] [diff] [review]
fix
Assignee: nobody → matspal
Attachment #578847 - Flags: review?(hsivonen)
Attachment #578847 - Flags: review?(hsivonen) → review+
Duplicate of this bug: 666281
(Assignee)

Comment 6

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e72b86326124
Whiteboard: [inbound]
Target Milestone: --- → mozilla10
(Assignee)

Updated

5 years ago
Target Milestone: mozilla10 → mozilla11
https://hg.mozilla.org/mozilla-central/rev/e72b86326124
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
(Reporter)

Comment 8

5 years ago
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 =)
Status: RESOLVED → VERIFIED
(Reporter)

Comment 9

5 years ago
Talked to soon?

Just crashed again with a little more informative crash signature, see bp-fd2b38ae-5600-4371-9770-ce6d22120313
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 10

5 years ago
Alex, that crash report looks like an unrelated problem, please file a new bug.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 11

5 years ago
(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.
You need to log in before you can comment on or make changes to this bug.