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
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.
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.
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 22.214.171.124 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? ;)
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.
(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).
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.
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.
I don't crash on 126.96.36.199 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.
Yes, it's fixed now. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52) Gecko/20091102 Firefox/3.5.5 ID:20091102134505
Henrik, did you verify the crash happening in 184.108.40.206 before verifying that it was fixed in 220.127.116.11?
See my comment 14.