i had just tried opening: https://addons.mozilla.org/en-US/firefox/downloads/file/29281/edit_middle-2-fx.xpi i did get a do you want to install and don't trust things you don't know. i said go for it... and i think that's about when it died. afaict this is a build from after most of the fixes for this signature (which seem to be march) Signature nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int) UUID 4b5ee4b0-14fd-11dd-8d4e-001321b13766 Time 2008-04-28 01:29:38-07:00 Uptime 314345 Product Firefox Version 3.0pre Build ID 2008041707 OS Windows NT OS Version 5.1.2600 Service Pack 2 CPU x86 CPU Info GenuineIntel family 6 model 13 stepping 8 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x4 Comments Crashing Thread Frame Module Signature Source 0 xul.dll nsFrame::BoxReflow mozilla/layout/generic/nsFrame.cpp:6359 1 xul.dll nsFrame::DoLayout mozilla/layout/generic/nsFrame.cpp:6043 2 xul.dll nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 3 xul.dll nsSprocketLayout::Layout mozilla/layout/xul/base/src/nsSprocketLayout.cpp:523 4 xul.dll nsBoxFrame::DoLayout mozilla/layout/xul/base/src/nsBoxFrame.cpp:946 5 xul.dll nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 6 xul.dll nsSprocketLayout::Layout mozilla/layout/xul/base/src/nsSprocketLayout.cpp:523 7 xul.dll nsBoxFrame::DoLayout mozilla/layout/xul/base/src/nsBoxFrame.cpp:946 8 xul.dll nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 9 xul.dll nsXULScrollFrame::LayoutScrollArea mozilla/layout/generic/nsGfxScrollFrame.cpp:2074 10 xul.dll nsXULScrollFrame::Layout mozilla/layout/generic/nsGfxScrollFrame.cpp:2228 11 xul.dll nsXULScrollFrame::DoLayout mozilla/layout/generic/nsGfxScrollFrame.cpp:1226 12 xul.dll nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 13 xul.dll nsBoxFrame::Reflow mozilla/layout/xul/base/src/nsBoxFrame.cpp:757 14 xul.dll nsLineLayout::ReflowFrame mozilla/layout/generic/nsLineLayout.cpp:859 15 xul.dll nsBlockFrame::ReflowInlineFrame mozilla/layout/generic/nsBlockFrame.cpp:3571 16 xul.dll nsBlockFrame::DoReflowInlineFrames mozilla/layout/generic/nsBlockFrame.cpp:3393 17 xul.dll nsBlockFrame::ReflowInlineFrames mozilla/layout/generic/nsBlockFrame.cpp:3242 18 xul.dll nsBlockFrame::ReflowLine mozilla/layout/generic/nsBlockFrame.cpp:2306 19 xul.dll nsBlockFrame::ReflowDirtyLines mozilla/layout/generic/nsBlockFrame.cpp:1887 20 xul.dll nsBlockFrame::Reflow mozilla/layout/generic/nsBlockFrame.cpp:951

a crash sort of like this is appearing as the #11 topcrash in very early fx3 data from the first 1/2 day of use. http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&range_unit=hours&version=Firefox%3A3.0&signature=nsFrame%3A%3ABoxReflow(nsBoxLayoutState%26%2C+nsPresContext*%2C+nsHTMLReflowMetrics%26%2C+nsIRenderingContext*%2C+int%2C+int%2C+int%2C+int%2C+int)&range_value=6 the stack trace on windows looks like Signature: nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int) 0 xul.dll nsFrame::BoxReflow mozilla/layout/generic/nsFrame.cpp:6302 1 xul.dll nsFrame::DoLayout mozilla/layout/generic/nsFrame.cpp:6108 2 xul.dll nsBoxFrame::LayoutChildAt mozilla/layout/xul/base/src/nsBoxFrame.cpp:2023 3 xul.dll LayoutAndInvalidate mozilla/layout/generic/nsGfxScrollFrame.cpp:2480 4 xul.dll nsGfxScrollFrameInner::LayoutScrollbars mozilla/layout/generic/nsGfxScrollFrame.cpp:2542 5 xul.dll nsHTMLScrollFrame::Reflow mozilla/layout/generic/nsGfxScrollFrame.cpp:823 6 xul.dll nsContainerFrame::ReflowChild mozilla/layout/generic/nsContainerFrame.cpp:771 7 xul.dll ViewportFrame::Reflow mozilla/layout/generic/nsViewportFrame.cpp:286 8 xul.dll PresShell::DoReflow mozilla/layout/base/nsPresShell.cpp:6280 9 xul.dll PresShell::ProcessReflowCommands mozilla/layout/base/nsPresShell.cpp:6386 10 xul.dll PresShell::DoFlushPendingNotifications mozilla/layout/base/nsPresShell.cpp:4574 11 xul.dll PresShell::ReflowEvent::Run mozilla/layout/base/nsPresShell.cpp:6145 12 xul.dll nsThread::ProcessNextEvent mozilla/xpcom/threads/nsThread.cpp:510 13 xul.dll nsBaseAppShell::Run mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170 14 nspr4.dll PR_GetEnv 15 firefox.exe wmain mozilla/toolkit/xre/nsWindowsWMain.cpp:87 16 firefox.exe firefox.exe@0x217f 17 kernel32.dll BaseProcessStart and most of the reports seem to be within seconds of start up. only a few comments: Updated to Firefox Portable 3 and now program won't run. it did not go to any other sites. Fresh download and untar.

dbaron, there is an old XXX comment near where we die. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsFrame.cpp&rev=3.802&mark=6302#6302 could that area be causing the problem?

I suspect bug 380015 describes part of the cause; the question is why we're getting into that case still.

(In reply to comment #1) > Fresh download and untar. Then again, this describes exactly why we're crashing. If you untar on top of an old release, you'll crash. Unfortunately, the fact that we pick up any components in the components directory is considered a feature of XPCOM (although maybe we could drop it at some point).

This is the #18 topcrasher. Of the 1345 crash reports with this signature in 3.0.1, all bug six are for Windows. Presumably the old-components theory wouldn't apply to normal Windows installs, so either these are abnormal Windows installs (Portable Firefox?) or there's some other cause.

(In reply to comment #5) > This is the #18 topcrasher. Of the 1345 crash reports with this signature in > 3.0.1, all bug six are for Windows. How abnormal is that platform ratio? Abnormal enough that you're comfortable saying this is a Windows installer bug?

The topcrashes tend to be very platform-specific, so it's not abnormal in that sense. Assuming that the problem is old components, I would think that the problem is with *some* installer or upgrader. Considering that Portable Firefox tells users to plunk the new version on top of the old[1], that'd be my guess. Once the crash server is acting nice, I'd like to see if further comments reference it. 1 - http://portableapps.com/support/firefox_portable#upgrading

we might be able to confirm this by looking at version numbers of loaded binary components in the modules list. anyone know if there is a list of version numbers of components for a release like 3.0.1 that gets generated and posted some where? going through reports "by hand" is another possibility, but that sounds painful.

It seems like this bug is just the same as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492488 as the stack trace is very similar. I am getting the crash on my x86-64 Debian GNU/Linux unstable with Firefox 3.0.1 but not on my similar x86 Linux system.

I can confirm this bug also on my x86-64 Debian GNU/Linux unstable with Firefox 3.0.3 I would like to help this bug get fixed but I do not know where the problem might be so if anyone wants me to make any tests or try any patches please let me know.

Please put any issues related to Linux distro packaging in a separate bug (although I think there may already be one).

dup of startup crash bug 533133 ?

checking --- 20091212-crashdata.csv nsFrame::BoxReflow signature list 536 nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int) Correlation to startup 536 total crashes for nsFrame::BoxReflow on 20091212-crashdata.csv 346 start up crashes with last crash inside 3 minutes Correlation to releases for reports on 2009 12 12 release total-crashes nsFrame::BoxReflow crashes pct. all 212262 536 0.00252518 3.0.15 38448 68 0.00176862 3.5.5 119155 236 0.00198061 3.6b4 20684 28 0.0013537 3.6b3 883 0 3.6b2 911 0 3.6b1 2351 8 0.00340281 it seems strange that on dec 12 we might be seeing this wide variation of occurences of the signature on older releases. all releases 9 3.0 11 3.0.1 20 3.0.10 6 3.0.11 3 3.0.12 5 3.0.13 7 3.0.14 68 3.0.15 1 3.0.2 1 3.0.4 8 3.0.5 3 3.0.6 4 3.0.7 3 3.0.8 1 3.0.9 9 3.1b2 12 3.1b3 13 3.5 7 3.5.1 13 3.5.2 24 3.5.3 24 3.5.4 236 3.5.5 1 3.5.6 1 3.5b4 8 3.6b1 28 3.6b4 10 3.7a1pre os breakdown 224 0.41791 Windows NT5.1.2600 Service Pack 3 171 0.31903 Windows NT5.1.2600 Service Pack 2 34 0.0634328 Windows NT6.1.7600 31 0.0578358 Windows NT6.0.6002 Service Pack 2 20 0.0373134 Windows NT6.0.6001 Service Pack 1 13 0.0242537 Windows NT6.0.6000 11 0.0205224 Windows NT5.1.2600 Szervizcsomag 3 11 0.0205224 Windows NT5.1.2600 Dodatek Service Pack 3 5 0.00932836 Windows NT5.1.2600 Service Pack 1 5 0.00932836 Windows NT5.1.2600 4 0.00746269 Windows NT5.1.2600 Dodatek Service Pack 2 2 0.00373134 Windows NT5.2.3790 Service Pack 2 2 0.00373134 Windows NT5.1.2600 Service Pack 3, v.3244 1 0.00186567 Windows NT6.1.7100 1 0.00186567 Windows NT5.1.2600 Szervizcsomag 2 525 <no url reported> 7 \N ull url reported but a few actually made it to some kind of start url. 1 http://www.kapitalism.de/main.php4?page=geb_fab&show=all&UIN= -sanitized-- 1 http://www.google.com.br/ 1 http://www.facebook.com/profile.php?ref=sgm&id= -sanitized-- 1 http://sixtofive1982.com/ -sanitized--

I was able to reproduce this three times in a row by setting *{ display: inline !important; } on (almost?) any site through the stylish addon.

(In reply to comment #17) > I was able to reproduce this three times in a row by setting > > *{ display: inline !important; } > > on (almost?) any site through the stylish addon. Magne, I cannot reproduce same issue using stylish + your CSS. But Firefox sometimes crash into other address ([@ nsTextControlFrame::CalcIntrinsicSize]) with your step. I will file a new bug for it. metrics seems to be null when this bug occurs. I don't know why BoxMetrics() returns null because we have stack data only. I believe that workaround is that we add check code whether metrics is null or not.

Historically this bug happens when Firefox is unable to read its user-agent style sheets for some reason. In such a situation, we're unable to produce a usable browser window anyway, so I think we're better off crashing so that we get the crash reports showing how many users have an installation that's broken in such a way as to cause this problem.

Or, alternatively, we could present an error message (dialog box?) explaining the problem. However, it would have to NOT be localized, since if we can't read our style sheets, we probably can't read our localization either.

Is the only corrective action to remove the installation and re-install, or start in safe mode and remove rogue addons? If the dialog box could help people get back on their feet that would also be useful.

(In reply to comment #21) > Is the only corrective action to remove the installation and re-install, or > start in safe mode and remove rogue addons? I don't think we know what the underlying problem is, and therefore don't know what will fix it.

the bulk of these crashes seems to migrate quickly to what ever we are offering and people are installing as the current product. I was noticing that this is now the #3 top crash for 3.6 its shifted quick to the bulk of these being from 3.6 now even though 3.5.7 still has significantly more users out there at this point. early startup crash snapshot from 2010 01 29 (within 3 seconds of launch) seconds since start up crash counts stack fx version 0 364 nsFrame::BoxReflow(nsBoxLayoutState& 3.6 0 79 nsFrame::BoxReflow(nsBoxLayoutState& 3.5.7 1 462 nsFrame::BoxReflow(nsBoxLayoutState& 3.6 1 71 nsFrame::BoxReflow(nsBoxLayoutState& 3.5.7 2 100 nsFrame::BoxReflow(nsBoxLayoutState& 3.6 2 16 nsFrame::BoxReflow(nsBoxLayoutState& 3.5.7 3 71 nsFrame::BoxReflow(nsBoxLayoutState& 3.6 3 8 nsFrame::BoxReflow(nsBoxLayoutState& 3.5.7 on comment 19 and 20 I wonder if there is any way to get at error info that might contributing to the problem? I'm thinking about things like -file missing -file permission/locking problem -general corruption could these kind of things be coming into play, and might be heightened during upgrade installs/updates? I guess it would also be interesting to understand if in fact we can read any file, or user-agent style sheets, or localization files, or list of files z-z.... One possible way to test might be to start removing or corrupting the series of files that get read at startup and see if we can hit this signature or other problems, then figure out possible defenses or error messages that might help the user to recover. does that make sense?

Top 10 crash for Thunderbird v3.1.2, all startup

This crash also happens at every startup (never managed to get a window yet) on OpenBSD-current with Firefox 4.0b6. BoxMetrics() returns null.. strange thing is that the assertion NS_ASSERTION(metrics, "A box layout method was called but InitBoxMetrics was never called"); is not triggered. in FramePropertyTable::Get(), mLastFrame == aFrame but mLastEntry is null, and then nsnull is returned. Program received signal SIGSEGV, Segmentation fault. 0x000000021194395f in nsFrame::BoxReflow (this=0x20b99c848, aState=@0x7f7ffffbd708, aPresContext=0x206b74000, aDesiredSize=@0x7f7ffffbd4e0, aRenderingContext=0x207b23080, aX=6000, aY=6000, aWidth=0, aHeight=0, aMoveFrame=1) at nsFrame.cpp:6690 6690 if (metrics->mLastSize.width != aWidth) (gdb) bt #0 0x000000021194395f in nsFrame::BoxReflow (this=0x20b99c848, aState=@0x7f7ffffbd708, aPresContext=0x206b74000, aDesiredSize=@0x7f7ffffbd4e0, aRenderingContext=0x207b23080, aX=6000, aY=6000, aWidth=0, aHeight=0, aMoveFrame=1) at nsFrame.cpp:6690 #1 0x0000000211945d1c in nsFrame::DoLayout (this=0x20b99c848, aState=@0x7f7ffffbd708) at nsFrame.cpp:6482 #2 0x0000000211a51878 in nsIFrame::Layout (this=0x20b99c848, aState=@0x7f7ffffbd708) at nsBox.cpp:568 #3 0x000000021194f21b in LayoutAndInvalidate (aState=@0x7f7ffffbd708, aBox=0x20b99c848, aRect=@0x7f7ffffbd630, aScrollbarIsBeingHidden=Variable "aScrollbarIsBeingHidden" is not available. ) at nsGfxScrollFrame.cpp:2974 #4 0x000000021194f331 in nsGfxScrollFrameInner::LayoutScrollbars (this=0x20b99c4c8, aState=@0x7f7ffffbd708, aContentArea=@0x7f7ffffbd760, aOldScrollArea=@0x7f7ffffbd790) at nsGfxScrollFrame.cpp:3069 #5 0x0000000211952d0d in nsHTMLScrollFrame::Reflow (this=0x20b99c440, aPresContext=Variable "aPresContext" is not available. ) at nsGfxScrollFrame.cpp:849 #6 0x00000002119378b2 in nsContainerFrame::ReflowChild (this=Variable "this" is not available. ) at nsContainerFrame.cpp:738 #7 0x00000002119964a4 in ViewportFrame::Reflow (this=0x20f992a38, aPresContext=0x206b74000, aDesiredSize=@0x7f7ffffbdc10, aReflowState=@0x7f7ffffbdb20, aStatus=@0x7f7ffffbdca4) at nsViewportFrame.cpp:293 #8 0x00000002119198dd in PresShell::DoReflow (this=0x208af8800, target=0x20f992a38, aInterruptible=0) at nsPresShell.cpp:7565 #9 0x0000000211919c80 in PresShell::ProcessReflowCommands (this=0x208af8800, aInterruptible=0) at nsPresShell.cpp:7700 #10 0x0000000211919fa6 in PresShell::FlushPendingNotifications (this=0x208af8800, aType=Flush_Layout) at nsPresShell.cpp:4812 #11 0x00000002118f847e in DocumentViewerImpl::LoadComplete (this=0x20f93dc00, aStatus=0) at nsDocumentViewer.cpp:996 #12 0x00000002120637c5 in nsDocShell::EndPageLoad (this=0x20b44ec00, aProgress=Variable "aProgress" is not available. ) at nsDocShell.cpp:5964 #13 0x000000021206a0d1 in nsDocShell::OnStateChange (this=0x20b44ec00, aProgress=0x20b44ec28, aRequest=0x202ceb848, aStateFlags=16, aStatus=0) at nsDocShell.cpp:5824 #14 0x000000021207b6bb in nsDocLoader::FireOnStateChange (this=0x20b44ec00, aProgress=0x20b44ec28, aRequest=0x202ceb848, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1334 #15 0x000000021207b9a8 in nsDocLoader::doStopDocumentLoad (this=0x20b44ec00, request=0x202ceb848, aStatus=0) at nsDocLoader.cpp:942 #16 0x000000021207bb0d in nsDocLoader::DocLoaderIsEmpty (this=0x20b44ec00, aFlushLayout=Variable "aFlushLayout" is not available. ) at nsDocLoader.cpp:818 #17 0x000000021207bf32 in nsDocLoader::OnStopRequest (this=0x20b44ec00, aRequest=0x2105c07d0, aCtxt=Variable "aCtxt" is not available. ) at nsDocLoader.cpp:702 #18 0x000000021179732c in nsLoadGroup::RemoveRequest (this=0x209bc2400, request=0x2105c07d0, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:680 #19 0x0000000211ac3956 in nsDocument::DoUnblockOnload (this=0x20a87a000) at nsDocument.cpp:7194 #20 0x0000000211ac5757 in nsDocument::DispatchContentLoadedEvents (this=0x20a87a000) at nsDocument.cpp:4112 #21 0x0000000211acbacf in nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run (this=0x0) at nsThreadUtils.h:347 #22 0x0000000212368740 in nsThread::ProcessNextEvent (this=0x209b8e700, mayWait=1, result=0x7f7ffffbe67c) at nsThread.cpp:547 #23 0x0000000212326e59 in NS_ProcessNextEvent_P (thread=Variable "thread" is not available. ) at nsThreadUtils.cpp:250 #24 0x0000000212269973 in nsBaseAppShell::Run (this=0x20c699d80) at nsBaseAppShell.cpp:178 #25 0x00000002120e03ae in nsAppStartup::Run (this=0x20a867b80) at nsAppStartup.cpp:191 #26 0x000000021177af12 in XRE_main (argc=Variable "argc" is not available. ) at nsAppRunner.cpp:3662

More details.. setting breakpoints in nsFrame.cpp on nsFrame::Init() and nsFrame::SetParent(), the only callers of InitBoxMetrics(). Init() is called 8 times, and each time *this contains always almost the same thing (only different ptr value for mStyleContext) : $4 = {<nsBox> = {<nsIFrame> = {<nsQueryFrame> = {_vptr$nsQueryFrame = 0x2102002f0}, static kFrameIID = nsQueryFrame::nsIFrame_id, mRect = {x = 0, y = 0, width = 0, height = 0}, mContent = 0x0, mStyleContext = 0x2053387d0, mParent = 0x0, mNextSibling = 0x0, mPrevSibling = 0x0, mState = 1026, mOverflow = {mType = 0, mDeltas = {mLeft = 0 '\0', mTop = 0 '\0', mRight = 0 '\0', mBottom = 0 '\0'}}}, static gGotTheme = 1, static gTheme = 0x206bb5800}, <No data fields>} But InitBoxMetrics() itself is never called.

here's the debug output of the nsFrame::Init() calls. InitBoxMetrics() is never called.

There are a few related bugs out there. Not sure if they are dups - bug 543593 and bug 519341. It's no longer a top crash since both signatures are very low volume (1 in 4 weeks on 8.0 and 7.0.1). Removing top crash keyword.

There are 9 crashes in TB 17.0.

There are very few crashes for these signatures in recent versions (19 total in v60+). The theory from comments above suggests that the root cause is a damaged installation, like in bug 1303764. I don't think it's worth tracking this as a Layout bug. The fix is to repair the installation somehow, see bug 315278.