527770 - New nsIFrame::GetStyleVisibility() crash in 3.5.4/5.

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Johnny Stenback (:jst)]

There's a new crash with the signature nsIFrame::GetStyleVisibility() that we've seen 350 instances in 3.5.5, 6 in 3.5.4, and none before that. So far this is looking like it's windows only, but not a specific version of windows.

The common stacks look like the one here:

http://crash-stats.mozilla.com/report/index/2b196a61-2ba3-4fda-9a5f-05a822091110

There's one instance of this on 1.9.2 or trunk as well, so it's not just a 1.9.1 bug.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we get URLs here or any more data?

Comment 2

[Johnny Stenback (:jst)]

The urls for this crash, of which there are 530 now, are all over the place, no one url or site stands out. There's everything from about:blank, about:sessionrestore, to facebook, google, youtube and so on. I have the list of urls, but I don't think they'll provide any help here :(

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

how about minidumps?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

roc noticed that there seem to be a disproportionate number of AMD CPUs in the sample.

I looked at the core-counts report and this crash turns out to be almost entirely single-core-only, which I've never seen before.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The only thing I can think of doing here is adding something to nsFrame::DisplayBorderBackgroundOutline and nsBoxFrame::BuildDisplayList which would cause an immediate crash if 'this' is null, e.g. a call to this->GetType(), and landing that on 1.9.2, and then seeing if that helps us narrow down the problem.

Comment 9

[Sheila Mooney]

I don't see this crash in the past 4 weeks on any version. I see a different crash for bug 634200. Resolving as works for me.