See testcase, which crashes on load in current trunk build. This bug was filed from the Socorro interface and is report bp-2114122a-3508-4ad4-9131-8f9082120608 . ============================================================= 0 xul.dll LossyAppendUTF16toASCII xpcom/string/src/nsReadableUtils.cpp:109 1 xul.dll NS_LossyConvertUTF16toASCII::NS_LossyConvertUTF16toASCII obj-firefox/dist/include/nsString.h:75 2 xul.dll nsString::ToDouble xpcom/string/src/nsStringObsolete.cpp:1012 3 xul.dll nsContentUtils::GetViewportInfo content/base/src/nsContentUtils.cpp:5016 4 xul.dll nsLayoutUtils::InflationMinFontSizeFor layout/base/nsLayoutUtils.cpp:4823 Also: https://crash-stats.mozilla.com/report/index/bp-ddec6d00-8ca2-4c39-abd8-756902120608 0 xul.dll nsTHashtable<nsBaseHashtableET<nsCStringHashKey,nsCOMPtr<mozIStorageStatement> > obj-firefox/dist/include/nsTHashtable.h:441 1 xul.dll SearchTable obj-firefox/xpcom/build/pldhash.cpp:400 2 xul.dll PL_DHashTableOperate obj-firefox/xpcom/build/pldhash.cpp:586 3 xul.dll nsComponentManagerImpl::GetServiceByContractID xpcom/components/nsComponentManager.cpp:1365 4 xul.dll CallGetService obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:62 5 xul.dll nsCOMPtr_base::assign_from_gs_contractid_with_error obj-firefox/xpcom/build/nsCOMPtr.cpp:108 6 xul.dll nsCOMPtr<nsIScreenManager>::nsCOMPtr<nsIScreenManager> obj-firefox/dist/include/nsCOMPtr.h:589 7 xul.dll nsContentUtils::GetViewportInfo content/base/src/nsContentUtils.cpp:5085 8 xul.dll nsBlockReflowState::nsBlockReflowState layout/generic/nsBlockReflowState.cpp:113 9 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:996 10 xul.dll nsContainerFrame::ReflowChild layout/generic/nsContainerFrame.cpp:907 11 xul.dll nsHTMLScrollFrame::ReflowScrolledFrame layout/generic/nsGfxScrollFrame.cpp:518 12 xul.dll nsHTMLScrollFrame::ReflowContents layout/generic/nsGfxScrollFrame.cpp:616 13 xul.dll nsHTMLScrollFrame::Reflow layout/generic/nsGfxScrollFrame.cpp:857 14 xul.dll nsBlockReflowContext::ReflowBlock layout/generic/nsBlockReflowContext.cpp:262 15 xul.dll nsBlockFrame::ReflowBlockFrame layout/generic/nsBlockFrame.cpp:3180 16 xul.dll nsBlockFrame::ReflowLine layout/generic/nsBlockFrame.cpp:2488 17 xul.dll nsBlockFrame::ReflowDirtyLines layout/generic/nsBlockFrame.cpp:1994 18 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:1043 19 xul.dll nsContainerFrame::ReflowChild layout/generic/nsContainerFrame.cpp:907 20 xul.dll nsColumnSetFrame::ReflowChildren layout/generic/nsColumnSetFrame.cpp:671 etc...

For me, with HW acceleration: bp-64d0ea24-4a6d-4010-b8a0-6aeaf2120608: _SEH_prolog4 bp-d89d5826-2c6f-4abb-8a7f-43f1c2120608: IsTargetProcess

The crash reports above have "Crash Reason: EXCEPTION_STACK_OVERFLOW" which is also what I'm seeing in local debug Linux builds. It's a cycle of: #6609 in PresShell::HandlePostedReflowCallbacks at layout/base/nsPresShell.cpp:3688 #6610 in PresShell::DidDoReflow at layout/base/nsPresShell.cpp:7230 #6611 in PresShell::ProcessReflowCommands at layout/base/nsPresShell.cpp:7529 #6612 in PresShell::FlushPendingNotifications at layout/base/nsPresShell.cpp:3848 The crash occurs in Fx13 and later, but not in Fx12 and Fx11.

Regression window(cached m-c) Good: http://hg.mozilla.org/mozilla-central/rev/5e756e59a794 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222190318 Bad: http://hg.mozilla.org/mozilla-central/rev/15d7708672c1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120223 Firefox/13.0a1 ID:20120223055919 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e756e59a794&tochange=15d7708672c1 Regression window(cached m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/90cb54bb0101 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222062519 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/f4e8839c28f5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222103820 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=90cb54bb0101&tochange=f4e8839c28f5

I think it's a regression from bug 726258.

(In reply to Scoobidiver from comment #4) > I think it's a regression from bug 726258. Yes, but the underlying problem is older than that. Bug 726258 removed the condition that saved us in the zero height case, but with an explicit height the problem also occurs in older builds. This testcase also crash Firefox 4.

Thunderbird 13 #8 crash Firefox 13 #18 crash FWIW, ~90% of firefox crash comments are non-English. Unable to estimate for firefox, but I think less than 50%

(In reply to Mats Palmgren [:mats] (on vacation) from comment #5) > Created attachment 631695 [details] > Testcase #2 (same as the first test, but with an added height:30px) > > (In reply to Scoobidiver from comment #4) > > I think it's a regression from bug 726258. > > Yes, but the underlying problem is older than that. Bug 726258 removed > the condition that saved us in the zero height case, but with an explicit > height the problem also occurs in older builds. This testcase also > crash Firefox 4. Regresson window with Testcase #2 Good: http://hg.mozilla.org/mozilla-central/rev/69e2e34ccddc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre ID:20100813065209 Crash: http://hg.mozilla.org/mozilla-central/rev/9fd11a17eb1a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre ID:20100813072506 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69e2e34ccddc&tochange=9fd11a17eb1a In local build, Last Good: 5d5752f83c61 First bad: 1bf9a4c8c8b4+6876b5b6d83c Triggered by: 1bf9a4c8c8b4 Markus Stange — Bug 572689 - Make nsSVGRenderingObservers observe elements instead of frames. r=roc

PresShell::HandlePostedReflowCallbacks(bool) bp-7f094b6a-9ec3-4f85-b4c0-e9de42120724

mats, have you a refined prognosis? at least 5 of the sigs are mostly startup

(In reply to Wayne Mery (:wsmwk) from comment #9) > at least 5 of the sigs are mostly startup Startup crashes with the same signature are most likely not this bug. Note that with stack exhaustion crashes like this, you'll get a mostly random signature at the top. This bug is about content observers causing the infinite loop listed in comment 2. I.e. something like this: <div id="f"> <div style="overflow: scroll; filter: url(#f);"></div> </div> I doubt that is the root cause for the Thunderbird startup crashes; We should file separate bugs for those.

Perhaps we should simply not support observing an ancestor?

If we did that and the DOM changed so it wasn't an ancestor we wouldn't pick that up and render it properly.

Comment on attachment 690329 [details] [diff] [review] patch https://tbpl.mozilla.org/?tree=Try&rev=b8f021503d89

Can you describe what's happening in this bug in more detail?

The following markup causes the issue: <div id="f"> <div style="overflow: scroll; filter: url(#f);"></div> </div> Anything that causes an update to the "f" div causes us to update elements that try to use it as a filter (even though it is invalid as they may previously have been valid) and as they are descendents of the filter element this causes us to update the filter as that is triggered by a refresh of its children and then we're on the train round and round and round again.

Can you given even more detail? nsSVGFilterProperty::DoUpdate queues a style change with RepaintFrame and UpdateOverflow. How does that lead its ancestor invalidating the filter property again?

Comment on attachment 690329 [details] [diff] [review] patch Review of attachment 690329 [details] [diff] [review]: ----------------------------------------------------------------- Clearing request while I wait for more info.

Fyi, this is still crashing.

Similar testcase, but this uses object and float

The testcases are all wfm now in current trunk build on the Mac.