Closed Bug 976125 Opened 7 years ago Closed 7 years ago

crash in nsCSSStyleSheet::GetOwningDocument() (probably really imgStatusTracker::GetImageStatus)

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox27 --- unaffected
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- wontfix

People

(Reporter: u279076, Unassigned)

References

Details

(Keywords: crash, topcrash-win)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-fa8895dc-9dfa-4ae7-9a20-ea9f82140224.
=============================================================
0 	xul.dll 	nsCSSStyleSheet::GetOwningDocument() 	layout/style/nsCSSStyleSheet.cpp
1 	xul.dll 	imgRequestProxy::GetImageStatus(unsigned int *) 	image/src/imgRequestProxy.cpp
2 	xul.dll 	nsImageRenderer::PrepareImage() 	layout/base/nsCSSRendering.cpp
3 	xul.dll 	nsCSSRendering::PrepareBackgroundLayer(nsPresContext *,nsIFrame *,unsigned int,nsRect const &,nsRect const &,nsStyleBackground const &,nsStyleBackground::Layer const &) 	layout/base/nsCSSRendering.cpp
4 	xul.dll 	nsDisplayBackgroundImage::GetBoundsInternal(nsDisplayListBuilder *) 	layout/base/nsDisplayList.cpp
5 	xul.dll 	xul.dll@0x88830 	

More Reports:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsCSSStyleSheet%3A%3AGetOwningDocument%28%29
=============================================================

This crash first showed up in Firefox 28.0b4 and has an explosiveness rating of 3.4 in the last 3-days. There are some crashes on Nightly and Aurora but over 90% are occurring on Beta right now.

Pushlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=1f89dd5f5d38&tochange=2985d92ccf72 

The only thing I see CSS related is bug 973344. Could this be more fallout from <input type=number>?
Flags: needinfo?(jwatt)
Flags: needinfo?(ehsan)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #0)
> 0 	xul.dll 	nsCSSStyleSheet::GetOwningDocument() 
> layout/style/nsCSSStyleSheet.cpp

I suspect the top frame of the stack here is bogus, and the crash is actually in imgStatusTracker::GetImageStatus -- I suspect nsCSSStyleSheet::mDocument and imgStatusTracker::mImageStatus are at the same offset in 32-bit.  I didn't actually check the offsets, though; it either requires a 32-bit build to test with or more trawling through base classes than I'd like to do right now.

(nsStyleImage::IsComplete is missing from the stack in comment 0  between PrepareImage and GetImageStatus, and nsCSSRendering::GetBackgroundLayerRect is missing between GetBoundsInternal and PrepareBackgroundLayer.)
Summary: crash in nsCSSStyleSheet::GetOwningDocument() → crash in nsCSSStyleSheet::GetOwningDocument() (probably really imgStatusTracker::GetImageStatus)
Bug 924282 looks like basically the same stack.

Was this previously showing up under another signature?  (Is function coalescing random?)
Flags: needinfo?(benjamin)
Yeah what David said makes sense here.
Flags: needinfo?(jwatt)
Flags: needinfo?(ehsan)
The input type=number changes are still among the most likely changes in the range, assuming that regression range is known to be solid.
It's reasonably likely that imgStatusTracker::GetImageStatus and nsCSSStyleSheet::GetOwningDocument have the same assembly and are therefore COMDAT-folded together. It is going to be random per-build which signature is assigned to the crash because of that.

I don't see any obvious candidates in the beta3 for this crash but I'd have to run a job to check the stack for imgRequestProxy::GetImageStatus to be sure.
See Also: → 924282
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #0)
> This crash first showed up in Firefox 28.0b4

That's not entirely correct. Looking at the number of crashes for the various build IDs over the last 28 days (from '2014-01-30T12:10:18+00:00' to '2014-02-26T19:56:52+00:00') we have:

28.0a2  20140129004017  1
28.0a2  20140130004003  4
28.0a2  20140202004003  8
28.0    20140218122424  400+

29.0a1  20140131095418  1
29.0a2  20140210004002  1
29.0a2  20140211004037  3
29.0a2  20140212004002  3
29.0a2  20140218004001  4
29.0a2  20140219004002  5
29.0a2  20140220004001  3
29.0a2  20140221004001  3
29.0a2  20140222004003  1

30.0a1  20140205030203  1
30.0a1  20140208030207  2
30.0a1  20140212030201  1
30.0a1  20140215030204  3
30.0a1  20140217030202  1
30.0a1  20140223030204  2

That said, clearly things got a lot worse in 20140218122424 (b4, presumably).
I went through dozens of the 20140218122424 crashed to see if I could find a URL to repro. Many were facebook.com or mail.google.com URLs, and of those that were not I didn't find a page that invoked the <input type=number> implementation, FWIW.
We seem to have skipped releasing b5 for some reason, but b6 seems to have been released now. There is a small chance that the crashes will go back down in b6 due to the fix for bug 973344 (this may just be a different form of fallout from the issue addressed in that bug). Since I didn't encounter any <input type=number> elements trawling the URLs of the crash reports this probably isn't directly related to the number input code.
(In reply to Jonathan Watt [:jwatt] from comment #8)
> There is a small chance that the crashes will go back
> down in b6 due to the fix for bug 973344

Actually that bug made b4, so scrap that.
Here's the current product breakdown for the last week:

Product Version Percent Crashes
===============================
Firefox 28.0b4 	94.50 %	344
Firefox 29.0a2 	4.40 %	16
Firefox 30.0a1 	1.10 %	4 

As you can see there are no crashes registering for Firefox 28.0b6. We should probably give this a few more days given we just released 28.0b6 yesterday. However, this may just end up being an anomaly; I'm not sure what could have caused this.
I think we can close this. Strange, but not something we can fix.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(benjamin)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.