Closed Bug 1454639 Opened 6 years ago Closed 2 years ago

Crash in style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf

Categories

(Core :: CSS Parsing and Computation, defect, P2)

Unspecified
Android
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 - wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 + wontfix
firefox66 + wontfix
firefox67 --- fix-optional
firefox68 --- affected

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, topcrash, Whiteboard: [priority:high])

Crash Data

This bug was filed from the Socorro interface and is
report bp-64d75fbf-7ce1-44e8-94ae-375820180417.
=============================================================

Seen while looking at Android nightly crash data: https://bit.ly/2qFHHnS. Crashes started using 20180416100101. These appear to be unique users hitting the crash.

One URL: https://m.bulbapedia.bulbagarden.net/wiki/Drapion_(Pok%C3%A9mon) 

Top 10 frames of crashing thread:

0 libxul.so style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf servo/components/style/stylist.rs:2153
1 libxul.so style::stylist::CascadeData::rebuild::h031df78c50950d64 servo/components/style/stylist.rs:2036
2 libxul.so geckoservo::glue::Servo_StyleSet_FlushStyleSheets servo/components/style/stylist.rs:262
3 libxul.so mozilla::ServoStyleSet::UpdateStylist layout/style/ServoStyleSet.cpp:1479
4 libxul.so mozilla::ServoStyleSet::AppendFontFaceRules layout/style/ServoStyleSet.cpp:1431
5 libxul.so nsIDocument::FlushUserFontSet dom/base/nsDocument.cpp:12478
6 libxul.so mozilla::PresShell::DoFlushPendingNotifications layout/base/PresShell.cpp:4265
7 libxul.so nsIDocument::FlushPendingNotifications dom/base/nsDocument.cpp:7586
8 libxul.so mozilla::dom::Element::GetPrimaryFrame dom/base/Element.cpp:2299
9 libxul.so mozilla::dom::Element::GetBoundingClientRect dom/base/Element.cpp:1076

=============================================================
Makoto, did anything change in the last couple of days wrt our Android builds?
Flags: needinfo?(m_kato)
(In reply to Cameron McCormack (:heycam) from comment #1)
> Makoto, did anything change in the last couple of days wrt our Android
> builds?

No, I think that this issue is related to bug 1451741 that may depend on Snapdragon 820/821 since this occurs on this CPU (Qualcomm Kryo) only.
Flags: needinfo?(m_kato)
Thanks.  In that case, not much to do here for now.
Priority: -- → P5
the issue is spiking up in fennec 61.0b11 (accounting for 18% of browser crashes so far) with new signatures.
Crash Signature: [@ style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf] → [@ style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf] [@ style::stylist::CascadeData::add_stylesheet] [@ style::stylist::CascadeData::add_stylesheet::h4556e427dda0aa93]
I assume this is related to bug 1466725 also. Is there anything we can try to do as a workaround here? This looking scary-frequent on b11 so far :(
Flags: needinfo?(emilio)
See Also: → 1466725
I'm not convinced this is related to that bug given this is not reproducible in any of the URLs there I've tried... Also it's really weird that this is beta only (it is, right?). Also, most of the stacks there look messed up (they don't make any sense).

The JIT uses a different stack layout which may confuse the unwinding code, maybe? Seems worth poking at some JS engine people just in case this is a bug in the ARM JIT...
Flags: needinfo?(emilio)
So I just talked with nbp, and apparently Android stacks being garbage is something not really uncommon...

Ryan, do you know where can I grab the build that's crashing to try to figuring out what's going on there?
Flags: needinfo?(ryanvm)
See Also: → 1451741
Adding an additional signature. We recently had a spike in the 20181016100107 nightly Fennec build, as well as the 63b11 Fennec build.
Crash Signature: [@ style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf] [@ style::stylist::CascadeData::add_stylesheet] [@ style::stylist::CascadeData::add_stylesheet::h4556e427dda0aa93] → [@ style::stylist::CascadeData::add_stylesheet::h56a83ef028e8faaf] [@ style::stylist::CascadeData::add_stylesheet] [@ style::stylist::CascadeData::add_stylesheet::h4556e427dda0aa93] [@ style::stylist::CascadeData::add_stylesheet::h00603db1ed9e561a]
Currently #4 overall top crash on Fennec 63 release. 2 of the top crashing devices are the Pixel and Pixel XL, which are devices QA should have. URLs are a mix of shopping sites, news sites, and social media sites. Adding Ioana in case we have the chance to try to reproduce. 

Comments:
*looking at a product on www.sears.com Entered my zip code to find proper store to shop and Firefox bellied up. 
*I was on lanebryant.com and Firefox crashed. This is like the 3rd time in the past week 

Also as a side note it would be interesting to understand why this affects Fennec more than desktop - there are crashes in desktop, but only a few.
Flags: needinfo?(ioana.chiorean)
Keywords: topcrash
We do have both Phones - Pixel and Pixel XL in the office. Let's try to get some more info. Thanks for the NI, Marcia.
Tested with the latest versions of Nightly, Beta and Release on a Google Pixel running Android P (9).

Browsed on a variety of sites (Facebook, Twitter, Amazon, eBay, Instagram, SportsDirect.. etc.) as well as the sites mentioned from Comment 10.

Sadly I could not reproduce any crash during my browsing session. Will be using FF on Pixel more often during testing in the following weeks to see if I manage to reproduce the crash.
It would great if someone else could take a look at these Fennec crashes (or is this just a crash we have to live with?). They are happening on beta, release and nightly. Devices all seem to be Snapdragon 820/821 processors.
Flags: needinfo?(sdaswani)
Flags: needinfo?(sdaswani)
Whiteboard: --do_not_change--[priority:high]
Whiteboard: --do_not_change--[priority:high] → [priority:high]
NI-ing Andrei to also have a look over this with the Pixel XL.
Flags: needinfo?(ioana.chiorean) → needinfo?(andrei.bodea)
I couldn't reproduce this issue with the latest versions of Nightly, Beta and release on Google Pixel C(Android 8.0) and Google Pixel XL (Android P).

I tried to reproduce the issue with the sites mentioned in Comment 10 and many other sites like Twitter, Amazon, Facebook...etc.
I also, will be using FF on Pixel more often during testing in the following weeks to see if I manage to reproduce the crash.
Flags: needinfo?(andrei.bodea)
Priority: P5 → P1
This is the top browser crash on Fennec nightly.
Andrei, Bogdan, can you guys check again with Nightly 66 ?
Flags: needinfo?(bogdan.surd)
Flags: needinfo?(andrei.bodea)
Checked again in the latest Nightly and still couldn't reproduce this crash.
Flags: needinfo?(bogdan.surd)
I checked again this issue on the latest Nightly build with a Google Pixel 3 XL(Android 9.0) and Google Pixel C(Android 8.0.0) but I couldn't reproduce it.
Flags: needinfo?(andrei.bodea)
I think that this issue depends on generated code and SoC.  So you should test this on 65.0b8 with SnapDragon 820/821 device (Google Pixel, not 2 and 3).
This is hitting 65.0b8, mostly on msm8996 boards.
(In reply to Makoto Kato [:m_kato] from comment #20)
> I think that this issue depends on generated code and SoC.  So you should
> test this on 65.0b8 with SnapDragon 820/821 device (Google Pixel, not 2 and
> 3).

The device I've tested on was a Pixel running Android P (Snapdragon 821), checked on 65.0b8 as well just now but was still not able to reproduce the issue.

[Tracking Requested - why for this release]: The signature "style::stylist::CascadeData::add_stylesheet" is ranked #1 for FennecAndroid top crashers (750 crashes for 65.0b8)

No crashes in 65.0b9 so far.

I'll track this for 65, I guess, though I'm not really sure what to do here besides keep my fingers crossed the RC build isn't affected...

As noted in the triage meeting, this signature follows a similar pattern on Fennec 66 nightly of coming and going. Last nightly crashes were in the build from the 12th.

Hi Sean -- Can I ask you to be the point person on this? Our release drivers are concerned about this one.

Assignee: nobody → svoisen
Flags: needinfo?(svoisen)
See Also: → 1518238

There doesn't appear to be any action we can take in this release to fix this bug. We are going to have to come up with some other way to get more information if this crash keeps popping up. In talking with the engineers on my team, the stacks don't make sense, and since this is limited to a single processor it's possible something else outside our own code is going on.

Will need to figure out if there's something going wrong with crash reporting when tracing from Rust code, or something going wrong for this particular architecture (or both?).

Flags: needinfo?(svoisen)

Still tracking for 66, though it appears the crash spike has gone down and no crashes since 66.0b4 and none since 66.0b3 in Fennec. Should we continue tracking for 65?

Flags: needinfo?(lhenry)

I don't think we need to keep tracking this. If we hit this crash in volume again, we will probably notice from crash-stats.

Flags: needinfo?(lhenry)

I'll leave 67 as unknown for now.

Deprioritizing for now unless it spikes again.

Priority: P1 → P2

Small spike in Fennec b14 - 27 crashes/6 installs. Socorro flagged it as a startup crash.

Emilio, can you see if this is still a viable issue? Listed as a critical crash but still open 3 years later, with low single occurances......Thanks

Assignee: sean → nobody
Flags: needinfo?(emilio)

Yeah this is likely some kind of external corruption or so. Given it doesn't affect any version past 91esr, it's single-digit crashes, and we have no repro, we can probably call this WFM.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(emilio)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.