Closed Bug 525276 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1
Tracking Flags:
Tracking Status
status1.9.2 --- unaffected
blocking1.9.1 --- .5+
status1.9.1 --- .5-fixed

People

(Reporter: dbaron, Unassigned)

References

Details

(4 keywords, Whiteboard: [sg:dos null-deref][fixed by 468562])

Crash Data

Attachments

(1 file)

wip
2.77 KB, patch
Details | Diff | Splinter Review 
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
Flags: blocking1.9.2?
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
Attached patch wip — — Splinter Review 
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
(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.
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?
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?
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
Closed: 15 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?
Keywords: regression
Crash Signature: [@ nsDocument::RegisterNamedItems(nsIContent*)]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: