The default bug view has changed. See this FAQ.

crashes [@ nsDocument::RegisterNamedItems(nsIContent*)]

VERIFIED FIXED in mozilla1.9.1

Status

()

Core
DOM
--
critical
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

(4 keywords)

Trunk
mozilla1.9.1
crash, regression, topcrash, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x ?

Firefox Tracking Flags

(status1.9.2 unaffected, blocking1.9.1 .5+, status1.9.1 .5-fixed)

Details

(Whiteboard: [sg:dos null-deref][fixed by 468562], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Crashes at nsDocument::RegisterNamedItems(nsIContent*) are the #20 topcrash for Firefox 3.5.4 so far.

Two of the 7 user comments are in Turkish, and a third references a turkish site:

whenever i click to link http://www.hurriyet.com.tr/spor/, it crashes!!!

The other comment with a URL is:
Was trying to do a "advanced search" on http://itu.org when it crashed. Had something like 20 tabs active


Full list of crashes at:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.4&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsDocument%3A%3ARegisterNamedItems%28nsIContent*%29



This is showing up on both Windows and Mac, and the top of the stack generally seems to be:

0  	xul.dll  	nsDocument::RegisterNamedItems  	 content/base/src/nsDocument.cpp:2364
1 	xul.dll 	nsDocument::ContentInserted 	content/base/src/nsDocument.cpp:2401
2 	xul.dll 	nsNodeUtils::ContentInserted 	content/base/src/nsNodeUtils.cpp:144
3 	xul.dll 	HTMLContentSink::NotifyInsert 	content/html/document/src/nsHTMLContentSink.cpp:3039
(Reporter)

Updated

8 years ago
Flags: blocking1.9.2?
(Reporter)

Updated

8 years ago
blocking1.9.1: --- → ?
We need an owner here. We're already talking about a short cycle for the new #1 topcrash. It'd be good to fix this as well.
blocking1.9.1: ? → .5+
Boris: Johnny suggested this might be related to changes you made during the 3.5.4 cycle. I think he was thinking of bug 489925, which touched that function.

I can work up some URLs if you think that'd help. Let me know.
> I think he was thinking of bug 489925

The patch landed in that bug was backed out in bug 522030.
Typical stack:

0 	xul.dll 	nsDocument::RegisterNamedItems 	content/base/src/nsDocument.cpp:2364
1 	xul.dll 	nsDocument::ContentInserted 	content/base/src/nsDocument.cpp:2401
2 	xul.dll 	nsNodeUtils::ContentInserted 	content/base/src/nsNodeUtils.cpp:144
3 	xul.dll 	HTMLContentSink::NotifyInsert 	content/html/document/src/nsHTMLContentSink.cpp:3039
4 	xul.dll 	xul.dll@0x32bbb6 	
5 	xul.dll 	HTMLContentSink::FlushTags 	content/html/document/src/nsHTMLContentSink.cpp:3237

6 	xul.dll 	nsContentSink::BeginUpdate 	content/base/src/nsContentSink.cpp:1609
7 	xul.dll 	nsDocument::BeginUpdate 	content/base/src/nsDocument.cpp:3752
8 	xul.dll 	CSSLoaderImpl::InsertSheetInDoc 	layout/style/nsCSSLoader.cpp:1235
9 	xul.dll 	CSSLoaderImpl::LoadStyleLink 	layout/style/nsCSSLoader.cpp:1826
10 	xul.dll 	nsStyleLinkElement::DoUpdateStyleSheet 	content/base/src/nsStyleLinkElement.cpp:313
11 	xul.dll 	nsGenericElement::InsertChildAt 	content/base/src/nsGenericElement.cpp:3203
12 	xul.dll 	HTMLContentSink::ProcessLINKTag 	content/html/document/src/nsHTMLContentSink.cpp:2948

That seems to be all the stacks I've looked at (random sampling of a dozen or so), in fact.

The crash is a null-pointer dereference of the aContent argument to RegisterNamedItems (and by extension ContentInserted).

We should NOT be passing null as aContent to ContentInserted.
Bug 502168 changed the NotifyInsert callsite in HTMLContentSink::FlushTags for 1.9.1.4 in a way that could potentially trigger this.  I bet we're getting a null |child| in some cases.  Olli, want to take a look?

Can we ship the HTML5 parser yet?  ;)
Blocks: 502168
Created attachment 409311 [details] [diff] [review]
wip

For some reason content sink handles *link* leaf tag in a such way that
sink context isn't used when appending the element to parent.
See http://mxr-test.konigsberg.mozilla.org/bonsai/cvsblame.cgi?file=content/html/document/src/nsHTMLContentSink.cpp&xrev=b67fcb2d3fe5&tree=mozilla1.9.1&mark=2428-2429,2433#2418

I need to still understand this all better, and do some testing.
The patch is almost like the one for Bug 468562.
Bug 468562 fixes the crash I see with http://www.hurriyet.com.tr/spor/.
And bug 468562 has been on trunk since last December, so we should probably
take it to branch(es?).
Dbaron, you marked this as blocking1.9.2? Can you actually reproduce this
on 1.9.2?
the crash happens if you load http://www.hurriyet.com.tr/_statikler/nesine.asp
1.9.2 seems unaffected.
Taking bug 468562 on 1.9.1 sounds like an excellent plan to me.
Depends on: 468562
(Reporter)

Comment 12

8 years ago
(In reply to comment #9)
> Dbaron, you marked this as blocking1.9.2? Can you actually reproduce this
> on 1.9.2?

No, just wanted to make sure it's fixed there too if still a problem.
Does this happen on 1.9.0? I'm guessing not since bug 502168 wasn't taken on that branch (and didn't apply to it, aiui).
status1.9.1: --- → wanted
Flags: wanted1.9.0.x?
Whiteboard: [fixed by 468562]
Yesterdays build of Namoroka crashed for me with this signature. So 1.9.2 is affected but as it looks like it will be fixed by bug 468562.
Forgot the crash report: bp-2b794016-5082-4ae1-9fb3-df9822091030
Henrik, bug 468562 was fixed back in November 2008, so that fix is on 1.9.2.

The crash report in comment 15 is from a 1.9.1 build, not a 1.9.2 build.
(In reply to comment #16)
> The crash report in comment 15 is from a 1.9.1 build, not a 1.9.2 build.

Oh, mixed up the running instances. Sorry. So 1.9.2 is fine and doesn't crash. A recent Grand Paradiso build also doesn't crash so 1.9.0 isn't affected.
Flags: blocking1.9.2?

Comment 18

8 years ago
I've got a similar case: Firefox crashed when i go on www.radioplay.ch
Report: http://crash-stats.mozilla.com/report/index/e06edb46-1da2-4575-8fbc-e94b12091101?p=1
Fixed by the patch in bug 468562.
blocking1.9.1: .6+ → .5+
status1.9.1: wanted → .5-fixed
Whiteboard: [fixed by 468562] → [sg:dos null-deref][fixed by 468562]
I don't crash on 1.9.1.4 at http://www.hurriyet.com.tr/_statikler/nesine.asp on OS X 10.6. Is this Windows only?
It also doesn't crash on XP and Vista on http://www.hurriyet.com.tr/_statikler/nesine.asp.
This is a 1.9.1-only crash. the underlying cause was fixed on 1.9.2 in the dependent bug a long time ago.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
status1.9.2: --- → unaffected
Resolution: --- → FIXED
Yes, it's fixed now. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 ID:20091102134505
Severity: normal → critical
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
Target Milestone: --- → mozilla1.9.1
Henrik, did you verify the crash happening in 1.9.1.4 before verifying that it was fixed in 1.9.1.5?
See my comment 14.
Keywords: regression
(Assignee)

Updated

6 years ago
Crash Signature: [@ nsDocument::RegisterNamedItems(nsIContent*)]
You need to log in before you can comment on or make changes to this bug.