539237 - Crash on session restore with large sites in tabs [@ nsIFrame::GetOrdinal(nsBoxLayoutState&) ]

Status: RESOLVED WONTFIX

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

Description

[cmtalbert]

This is a bug I just encountered loading my Minefield profile in 3.6 RC1.  I have a couple of tinderbox logs in the profile - things like: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262866252.1262875928.11492.gz&fulltext=1 and about 20 other tabs.  On restore, the browser comes up, and attempts to rebuild all the tabs.  The tinderbox tabs never completely return (which is why I'm picking on them), Firefox takes up all the memory on the system, topping out around 2 Gb of "Real Mem" according to Activity Monitor and then crashes.  There are three crash reports, two are mine:

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6&query_search=signature&query_type=startswith&query=nsIFrame%3A%3AGetOrdinal&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsIFrame%3A%3AGetOrdinal%28nsBoxLayoutState%26%29

FWIW, this does not occur on Minefield.  Minefield can load these tabs without any problem at all.  As this is reproducible at the moment on my system (doesn't seem like it is reproducible in general, these loading bugs almost never are) I'm happy to help reproduce it.

Not sure if this is being seen more widely or not, CCing Juan and Marcia to figure out if this should block 3.6 or not.

Comment 1

[cmtalbert]

Bz, do you think this is something we should worry about for 3.6 -- it seems to be crashing while reflowing?

I'll spin up a 1.9.2 debug build to see if it is reproducible there to get you more information.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Worry, yes.  If not for initial release then at least for 1.9.2.x.

Looking at those breakpad stacks, the crash address is 0x8 for all three of them.  The top two frames on the stack are bogus (in the "not called from NS_NewContinuingTextFrame" sense) for Clint's crashes.  The third crash crashes at same address, but from NS_NewInlineFrame.

For Clint's crashes, the file/line from frame 2 is the nsTextFrame constructor.

NS_NewContinuingTextFrame actually just creates an nsContinuingTextFrame using the usual nsIFrame placement new.

0x8, if the nsIFrame* is a null pointer, points somewhere inside its mRect on 1.9.2, right?  Or is it somewhere inside its vtable or something?

The nsFrame constructor does write to members, but the first one it writes to is mState, which is a lot further than 8 bytes from the start of the object.  It _is_ 8 words away, however (on 32-bit).  But I assume that breakpad on Mac reports bytes for the crash address, not words, right?

Comment 3

[(not currently active) Ted Mielczarek]

The Darwin docs say:
"subcode contains the bad memory address"
http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/catch_exception_raise.html

So I presume it's bytes.

Comment 4

[cmtalbert]

This is related to having HTML5 parsing enabled.  Without that setting, there is no crash.

Comment 5

[Henri Sivonen (:hsivonen)]

If this happens on 1.9.2 with html5=enable but not on trunk, this shouldn't block HTML5 parsing. (The HTML5 parser on the 1.9.2 branch is broken and not getting fixes. See bug 538722 about hard-disabling the HTML5 parser on the 1.9.2 branch.)

Comment 6

[cmtalbert]

(In reply to comment #5)
> If this happens on 1.9.2 with html5=enable but not on trunk, this shouldn't
> block HTML5 parsing. (The HTML5 parser on the 1.9.2 branch is broken and not
> getting fixes. See bug 538722 about hard-disabling the HTML5 parser on the
> 1.9.2 branch.)
That is indeed the case (broken on 1.9.2, works on trunk).  So this should be Resolved WONTFIX then right?

Marking as such...since we know the parser is broken, and we know we're not going to fix it on 1.9.2 then let's not waste bug space on it :)