Closed
Bug 525276
Opened 15 years ago
Closed 15 years ago
crashes [@ nsDocument::RegisterNamedItems(nsIContent*)]
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla1.9.1
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)
(deleted),
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
Reporter | ||
Updated•15 years ago
|
Flags: blocking1.9.2?
Reporter | ||
Updated•15 years ago
|
blocking1.9.1: --- → ?
Comment 1•15 years ago
|
||
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+
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
> I think he was thinking of bug 489925
The patch landed in that bug was backed out in bug 522030.
Comment 4•15 years ago
|
||
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.
Comment 5•15 years ago
|
||
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
Comment 6•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
The patch is almost like the one for Bug 468562.
Comment 8•15 years ago
|
||
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?).
Comment 9•15 years ago
|
||
Dbaron, you marked this as blocking1.9.2? Can you actually reproduce this
on 1.9.2?
Comment 10•15 years ago
|
||
the crash happens if you load http://www.hurriyet.com.tr/_statikler/nesine.asp
1.9.2 seems unaffected.
Comment 11•15 years ago
|
||
Taking bug 468562 on 1.9.1 sounds like an excellent plan to me.
Depends on: 468562
Reporter | ||
Comment 12•15 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.
Comment 13•15 years ago
|
||
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).
Comment 14•15 years ago
|
||
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.
Comment 15•15 years ago
|
||
Forgot the crash report: bp-2b794016-5082-4ae1-9fb3-df9822091030
Comment 16•15 years ago
|
||
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.
Comment 17•15 years ago
|
||
(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•15 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
Updated•15 years ago
|
Whiteboard: [fixed by 468562] → [sg:dos null-deref][fixed by 468562]
Comment 20•15 years ago
|
||
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?
Comment 21•15 years ago
|
||
It also doesn't crash on XP and Vista on http://www.hurriyet.com.tr/_statikler/nesine.asp.
Comment 22•15 years ago
|
||
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.
Comment 23•15 years ago
|
||
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
Comment 24•15 years ago
|
||
Henrik, did you verify the crash happening in 1.9.1.4 before verifying that it was fixed in 1.9.1.5?
Comment 25•15 years ago
|
||
See my comment 14.
Updated•15 years ago
|
Keywords: regression
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsDocument::RegisterNamedItems(nsIContent*)]
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•