Closed Bug 1229850 Opened 9 years ago Closed 9 years ago

[e10s] crash in nsComboboxControlFrame::GetAvailableDropdownSpace

Categories

(Core :: Layout: Form Controls, defect)

Unspecified
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla46
Tracking Status
e10s m8+ ---
firefox45 --- fixed
firefox46 --- fixed

People

(Reporter: dbaron, Assigned: jimm)

References

Details

(Keywords: crash, topcrash, topcrash-win)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is report bp-d0a8f47f-7665-4a2b-b124-70a5e2151202. ============================================================= These crashes have a crash address of 0xfffffffff0de801b or 0xffffffffffffffff. These crashes are occurring only on nightly and aurora -- but they started happening at any decent frequency on nightly and aurora on the same date, 2015-10-15, which makes me think the cause might be some Web content change in the wild. Though there were 3 crashes on nightly in the few months prior to that. It seems possible they'll start showing up on beta at the next merge, although the behavior of starting on aurora and nightly on the same date is pretty odd, so I'm not entirely sure. It seems worth looking into, especially if the crash is obvious from one of the crash reports.
I notice that there's at least one report from a build as far back as 41.0a1 (although it occurred within the past week -- someone was running an old build: 20150526030202). So it's apparently not a particularly recent regression in Gecko, though as you suggest, it may be triggered by something that's recently appeared on the web. FWIW, I also notice that all the crashes appear to be with e10s enabled. Don't know if that's at all significant. > These crashes have a crash address of 0xfffffffff0de801b or 0xffffffffffffffff. It looks like the former occurs in 32-bit Windows builds, and the latter in 64-bit Windows builds. There are also a few (32-bit) Linux crashes, with an address 0xf0dea81b that looks eerily similar (but not identical) to the 32-bit Windows one. But I don't know what it signifies, if anything.
I think f0de801b is a small offset from the default frame poison address: http://hg.mozilla.org/mozilla-central/file/f6ac392322b3/mfbt/Poison.cpp#l164 The e10s correlation makes the nightly/aurora thing make more sense.
tracking-e10s: --- → ?
Summary: crash in nsComboboxControlFrame::GetAvailableDropdownSpace → [e10s] crash in nsComboboxControlFrame::GetAvailableDropdownSpace
Assignee: nobody → jmathies
2015110300 1 2015111906 3 2015112000 2 2015112100 2 2015112300 42 2015112400 1 2015112500 20 2015112503 2 2015112600 24 2015112603 2 2015112700 5 2015112800 4 2015112900 5 2015112903 3 2015113000 3 2015113003 16 2015120100 49 2015120103 78 2015120200 135 2015120203 74 2015120211 60 2015120300 14 2015120303 16 2015120305 19 11-22: abbd213422a560f1180c4ec6e3bf4792c2ea81ba 11-23: 8b1fc0961a076e35646d0472a81feefc0074558c 22 -> 23: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=abbd213422a560f1180c4ec6e3bf4792c2ea81ba&tochange=8b1fc0961a076e35646d0472a81feefc0074558c 11-24: 45273bbed8efaface6f5ec56d984cb9faf4fbb6a 11-25: 099f695d31326c39595264c34988a0f4b7cbc698 11-26: c321d84038519dcf1670d59fd2c5c00ad8a85a55 11-27: 47b49b0d32360fab04b11ff9120970979c426911 11-28: 47b49b0d32360fab04b11ff9120970979c426911 11-29: 47b49b0d32360fab04b11ff9120970979c426911 11-30: 47b49b0d32360fab04b11ff9120970979c426911 26 -> 30: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c321d84038519dcf1670d59fd2c5c00ad8a85a55&tochange=47b49b0d32360fab04b11ff9120970979c426911 12-01: 66a6d7ec9534b9d7847b665142fef0dd87623768 30 -> 01: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47b49b0d32360fab04b11ff9120970979c426911&tochange=66a6d7ec9534b9d7847b665142fef0dd87623768
Not much stands out here.
tracing that PresContext() call - http://hg.mozilla.org/mozilla-central/annotate/59c648a3f955/layout/forms/nsComboboxControlFrame.cpp#l599 599 nsPresContext* pc = PresContext()->GetToplevelContentDocumentPresContext(); http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsIFrame.h#433 433 nsPresContext* PresContext() const { 434 return StyleContext()->PresContext(); 435 } http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsIFrame.h#542 542 nsStyleContext* StyleContext() const { return mStyleContext; } http://mxr.mozilla.org/mozilla-central/source/layout/style/nsStyleContext.h#135 135 nsPresContext* PresContext() const { return mRuleNode->PresContext(); } 582 // The rule node is the node in the lexicographic tree of rule nodes 583 // (the "rule tree") that indicates which style rules are used to 584 // compute the style data, and in what cascading order. The least 585 // specific rule matched is the one whose rule node is a child of the 586 // root of the rule tree, and the most specific rule matched is the 587 // |mRule| member of |mRuleNode|. 588 nsRuleNode* const mRuleNode; http://mxr.mozilla.org/mozilla-central/source/layout/style/nsRuleNode.h#885 884 // NOTE: Does not |AddRef|. Never null. 885 nsPresContext* PresContext() const { return mPresContext; }
bz, curious if you could take a look at these push ranges to see if anything stands out to you layout related? This crash doesn't appear to be e10s specific, although it only shows up in the content process. A nsRuleNode or the nsPresContext in a nsRuleNode is invalid when it shouldn't be.
Flags: needinfo?(bzbarsky)
Nothing jumping out at me offhand. There are various style system and layout changes in http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47b49b0d32360fab04b11ff9120970979c426911&tochange=66a6d7ec9534b9d7847b665142fef0dd87623768 but not obviously related to comboboxes. Of course there are lots of changesets in all those that could have some bug that corrupts memory or whatnot...
Flags: needinfo?(bzbarsky)
Not sure why that push range is interesting. See regression range info in comment 0. (Note that crash-stats defaults to showing only crashes in the past week, but you can change that by adding date > 2015-07-01 or similar.)
Note that I consider the e10s theory particularly credible because comboboxes work differently in e10s (from bug 897060).
A list of top sites affected by this might help.
Flags: needinfo?(twalker)
facebook.com and google search queries account for the bulk of reports. dbaron hid my previous post, for what he felt were privacy concerns (comment 3) that listed more specifically the urls. I can send you a detailed list, but I don't think it will be any more useful.
Flags: needinfo?(twalker)
Attached patch patchSplinter Review
I think the most straight forward fix here is to avoid doing these unnecessary drop down calculations in the content process. This will avoid the crash because the code involved never gets called. https://treeherder.mozilla.org/#/jobs?repo=try&revision=54b8ed7a562b
Comment on attachment 8700122 [details] [diff] [review] patch Looks good on try and should avoid this crash by avoiding executing drop down calculations code in the content process. We don't need to do this here, the drop down is managed in chrome.
Attachment #8700122 - Flags: review?(dbaron)
Comment on attachment 8700122 [details] [diff] [review] patch I wonder if nsListControlFrame::ReflowAsDropdown could do even less work, but this looks fine for now. r=dbaron
Attachment #8700122 - Flags: review?(dbaron) → review+
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Crash is gone from crash-stats in today's nightly, based on links in http://dbaron.org/mozilla/crashes-by-build . Thanks.
Status: RESOLVED → VERIFIED
Comment on attachment 8700122 [details] [diff] [review] patch Approval Request Comment [Feature/regressing bug #]: e10s combo box drop down work [User impact if declined]: crashed tabs [Describe test coverage new/current, TreeHerder]: on mc since Dec. 23rd. [Risks and why]: pretty low risk, e10s specific, patch shunts some code that shouldn't run. no fallout detected thus far on mc. [String/UUID change made/needed]: none
Attachment #8700122 - Flags: approval-mozilla-aurora?
Comment on attachment 8700122 [details] [diff] [review] patch Fix a crash, taking it.
Attachment #8700122 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1488828
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: