Closed Bug 976125 Opened 7 years ago Closed 7 years ago
crash in ns
CSSStyle Sheet::Get Owning Document() (probably really img Status Tracker::Get Image Status)
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>?
(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?)
Yeah what David said makes sense here.
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.
(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
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.