Closed Bug 436232 Opened 12 years ago Closed 2 years ago

startup crash [@ nsFrame::BoxReflow] on Windows (due to bad install?) (does not cover crashes due to Linux distro problems) [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]

Categories

(Core :: Layout: Block and Inline, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: timeless, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [crashkill][tbird crash])

Crash Data

Attachments

(1 file, 2 obsolete files)

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?
Keywords: topcrash
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.
Summary: crash [@ nsFrame::BoxReflow] → crash [@ nsFrame::BoxReflow] on Windows (does not cover crashes due to Linux distro problems)
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 ?
Summary: crash [@ nsFrame::BoxReflow] on Windows (does not cover crashes due to Linux distro problems) → startup crash [@ nsFrame::BoxReflow] on Windows (due to bad install?) (does not cover crashes due to Linux distro problems) [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Whiteboard: [crashkill]
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
Whiteboard: [crashkill] → [crashkill][tbird topcrash]
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.
Crash Signature: [@ nsFrame::BoxReflow] [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
Crash Signature: [@ nsFrame::BoxReflow] [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)] → int, int, int, int, int) ]nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsRenderingContext*, int, int, int, int, bool) ] [@ [@ nsFrame::BoxReflow] [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics…
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.
Keywords: topcrash
There are 9 crashes in TB 17.0.
Crash Signature: int, int, int, int, int) ]nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsRenderingContext*, int, int, int, int, bool) ] [@ → int, int, int, int, int) ] [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsRenderingContext*, int, int, int, int, bool)]
Whiteboard: [crashkill][tbird topcrash] → [crashkill][tbird crash]
Depends on: 1063052
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 315278
No longer depends on: 1063052
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.