See testcase, which crashes current trunk build on print preview. This regressed between 2010-08-04 and 2010-08-08: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-04+04%3A00%3A00&enddate=2010-08-08+06%3A00%3A00 I think a regression from bug 563584. http://crash-stats.mozilla.com/report/index/3359ff65-a788-4b0f-b052-f2e3a2100912 0 xul.dll nsTableFrame::MarkIntrinsicWidthsDirty layout/tables/nsTableFrame.cpp:1476 1 xul.dll PresShell::FrameNeedsReflow layout/base/nsPresShell.cpp:3447 2 xul.dll nsBlockFrame::RemoveFrame layout/generic/nsBlockFrame.cpp:4975 3 xul.dll nsPlaceholderFrame::DestroyFrom layout/generic/nsPlaceholderFrame.cpp:169 4 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:316 5 xul.dll nsContainerFrame::DestroyFrom layout/generic/nsContainerFrame.cpp:272 6 xul.dll nsContainerFrame::DestroyFrom layout/generic/nsContainerFrame.cpp:272 7 xul.dll nsContainerFrame::DestroyFrom layout/generic/nsContainerFrame.cpp:272 8 xul.dll nsContainerFrame::DestroyFrom layout/generic/nsContainerFrame.cpp:272 9 xul.dll nsTableFrame::DestroyFrom layout/tables/nsTableFrame.cpp:269 10 xul.dll nsContainerFrame::DestroyFrom layout/generic/nsContainerFrame.cpp:272 11 xul.dll nsTableOuterFrame::DestroyFrom layout/tables/nsTableOuterFrame.cpp:220 12 xul.dll nsIFrame::Destroy layout/generic/nsIFrame.h:538 13 xul.dll nsBlockFrame::DoRemoveFrame layout/generic/nsBlockFrame.cpp:5322 14 xul.dll RemoveBlockChild etc..

the attached testcase crashes my debug build on exit 1. load testcase 2. print preview 3. close print preview 4. close browser 5. hit ###!!! ABORT: Removing image that wasn't in the tracker!: 'found', file d:/moz_s rc/src/content/base/src/nsDocument.cpp, line 8030 ==> crash I am updating my build to see if this happens also with tip

We're destroying a table frame 0x7fffd3438478 (red) that has two next-in-flows. What happens is this: 1. nsBlockFrame::DoRemoveFrame on the first-in-flow, which Destroys it and calls DeleteNextInFlowChild() on the next-in-flow (blue) 2. nsBlockFrame::DoRemoveFrame on the 2nd-in-flow (blue) calls Destroy which finds a descendant placeholder (cyan) which calls RemoveFrame on the out-of-flow (lime) 3. at the end of nsBlockFrame::RemoveFrame we call FrameNeedsReflow which calls MarkIntrinsicWidthsDirty on ancestors, see the stack backtrace at the end. 4. on the ancestor table frame 0x7fffd343ef28 (yellow) we end up in nsTableFrame::MarkIntrinsicWidthsDirty which does LayoutStrategy()->MarkIntrinsicWidthsDirty(); and nsITableLayoutStrategy* LayoutStrategy() const { return static_cast<nsTableFrame*>(GetFirstInFlow())-> mTableLayoutStrategy; } The problem is that 'mTableLayoutStrategy' is only set on the first-in-flow which we Destroyed in 1 and unhooked from the flow chain so GetFirstInFlow() is now the original 2nd-in-flow which has mTableLayoutStrategy==NULL so we crash...

This should fix it. The 2nd testcase works for me but I included it in any case. I think long term we should make nsBlockFrame::DoRemoveFrame remove next-in-flows in last-to-first order like nsContainerFrame::DeleteNextInFlowChild does, but that seems a too risky change to do at this point.

http://hg.mozilla.org/mozilla-central/rev/f8e81c8196d2 http://hg.mozilla.org/mozilla-central/rev/c2e13e39c486 http://hg.mozilla.org/mozilla-central/rev/b91e7cab0613