Closed Bug 1423895 Opened 8 years ago Closed 8 years ago

Crash in core::option::expect_failed | style::stylist::Stylist::insert_stylesheet_before

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Platform:
Unspecified
Windows 8
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla62
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- fixed

People

(Reporter: marcia, Assigned: emilio)

References

(Depends on 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match.
59 bytes, text/x-review-board-request
bzbarsky
: review+
Details
This bug was filed from the Socorro interface and is report bp-06a536b0-efcf-473c-afb5-7214b0171201. ============================================================= Seen while looking at nightly crash data - crashes started using 20171030103605 (58 was in nightly): http://bit.ly/2AkmRBi. ni on Emilio since he worked in this area of code. Crashing reason: `before_sheet` stylesheet not found Top 10 frames of crashing thread: 0 xul.dll std::panicking::rust_panic_with_hook src/libstd/panicking.rs:583 1 xul.dll std::panicking::begin_panic<alloc::string::String> src/libstd/panicking.rs:538 2 xul.dll std::panicking::begin_panic_fmt src/libstd/panicking.rs:522 3 xul.dll core::panicking::panic_fmt src/libcore/panicking.rs:70 4 xul.dll core::option::expect_failed src/libcore/option.rs:839 5 xul.dll style::stylist::Stylist::insert_stylesheet_before servo/components/style/stylist.rs:560 6 xul.dll geckoservo::glue::Servo_StyleSet_InsertStyleSheetBefore servo/ports/geckolib/glue.rs:1172 7 xul.dll mozilla::ServoStyleSet::AddDocStyleSheet layout/style/ServoStyleSet.cpp:840 8 xul.dll nsDocument::AddStyleSheetToStyleSets dom/base/nsDocument.cpp:4579 9 xul.dll nsDocument::InsertStyleSheetAt dom/base/nsDocument.cpp:4722 =============================================================
Flags: needinfo?(emilio)
These are all from extensions... I don't see anything obvious, and without STR it's quite hard to investigate. Apparently the UUIDs that are in the crash reports can't really identify the crashing extension :( I'll ask around to see if anybody knows what the best way to debug this is, but given it's only a couple installations and I cannot know what's going on...
Flags: needinfo?(emilio)
Depends on: 1424285
Depends on: 1424409
Andy: Can you help show emilio and I how to map a UUID like {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d} to an actual extension version? In this specific instance, the reporter has multiple adblocker-type extensions that insert and/or remove stylesheets from the content page. We may have to create new guards to prevent that from crashing. Thanks!
Flags: needinfo?(amckay)
Priority: -- → P3
Sadly, the UUID is a locally generated install value, so we can't map to an add-on ID in the crash. The only person who can do that is the reporter. Just going to cc :rpl who has been looking at the insertCSS code recently as part of bug 1420485.
Flags: needinfo?(amckay)
I'm sometimes getting such crashes in Enigmail with Thunderbird 60b7 (and with TB 61a1). This is the code I'm using: let domWindowUtils = window.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils); domWindowUtils.loadSheetUsingURIString("chrome://messenger/skin/", 1); Any idea what I would need to fix?
Actually I was wrong. The crash occurs when opening a XUL file like this, loaded via window.openDialog(): <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <?xml-stylesheet href="chrome://communicator/skin/" type="text/css"?> <?xml-stylesheet href="chrome://enigmail/skin/enigmail.css" type="text/css"?> <dialog> ... </dialog> enigmail.css is available from here: https://gitlab.com/enigmail/enigmail/blob/master/ui/skin/tb-mac/enigmail.css The imported CSS files in enigmail.css are available from here: https://gitlab.com/enigmail/enigmail/tree/master/ui/skin/common
(In reply to Patrick Brunschwig from comment #5) > Actually I was wrong. The crash occurs when opening a XUL file like this, > loaded via window.openDialog(): > > <?xml version="1.0"?> > > <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> > <?xml-stylesheet href="chrome://communicator/skin/" type="text/css"?> > <?xml-stylesheet href="chrome://enigmail/skin/enigmail.css" type="text/css"?> > > <dialog> > ... > </dialog> > > > enigmail.css is available from here: > https://gitlab.com/enigmail/enigmail/blob/master/ui/skin/tb-mac/enigmail.css > > The imported CSS files in enigmail.css are available from here: > https://gitlab.com/enigmail/enigmail/tree/master/ui/skin/common Is there no script involved there? That'd be somewhat surprising. @import shouldn't matter there... Do you have a crash-stats url by any chance? Thanks for making enigmail btw, it's awesome :-)
Flags: needinfo?(patrick)
I guess I can assume stuff like: https://crash-stats.mozilla.com/report/index/07763533-f5bf-4206-a110-602040180609 Is a crash of yours :). That looks like a bug in the XUL code. I'd rather not wallpaper it in style. Getting clear STR or a XUL test-case that repros the issue would be awesome. I can try to construct one based on comment 5.
Yes, that's one of "my" crashes.
Flags: needinfo?(patrick)
A Mac example is bp-d88c89b0-4d67-4042-869e-1d8420180610 with slightly different signature mozalloc_abort | abort | core::option::expect_failed | style::stylist::Stylist::insert_stylesheet_before
60.0b7 build id 20180608022406 - no crash on Arch Linux using Enigmail Nightly 847b3a00-7ab1-11d4-8f02-006008948af5 - test email sent & received 62.0a1 build id 20180610101518 - crashes on Arch Linux using Enigmail Nightly 847b3a00-7ab1-11d4-8f02-006008948af5 - test would not send - navigating to any Enigmail options immediately crashes - https://crash-stats.mozilla.com/report/index/bp-e10534dd-7897-4f38-96f8-142100180610
The crash can also be reproduced on 60.0b7 if Enigmail 2.0.6.1 is installed together with CardBook.
Comment 11 reproduces here on Arch Linux too.
Flags: needinfo?(emilio)
So, I built Thunderbird trunk and installed enigmail and cardbook (I had to comment out[1] for that to succeed) and I couldn't repro it. I also tried to window.openDialog a file with the contents mentioned in comment 5 from the content toolbox, but that didn't work out (probably because I was trying to load it from file:// url). Jorg, do you know how can I build beta? Or alternatively, either Patrick or somebody else, do you know of a way of reproducing it on trunk? Note that I'm not familiar with all the whole add-ons stuff, so detailed STR would be best if possible. Thank you!
Flags: needinfo?(patrick)
Flags: needinfo?(jorgk)
Flags: needinfo?(emilio)
Which version of Enigmail did you try? 2.0.6.1 or a nightly build? I tried to implement a workaround in the nightly build which seems to work sometimes. STR: would be 1. install both Enigmail & Cardbook 2. open the preferences window in Enigmail (menu Enigmail > Preferences)
Flags: needinfo?(patrick)
You can build beta just as you can build trunk, I assume, without having tried it. Check out M-C, create a comm/ directory, check out C-B into that. Create a .mozconfig with |ac_add_options --enable-application=comm/mail| and all the other usual stuff. I'm using Enigmail 2.0.6.1 which Patrick sent me on a TB 60 beta 7.
Flags: needinfo?(jorgk)
(In reply to Jorg K (GMT+2) from comment #17) > You can build beta just as you can build trunk, I assume, without having > tried it. Check out M-C, create a comm/ directory, check out C-B into that. > Create a .mozconfig with |ac_add_options --enable-application=comm/mail| and > all the other usual stuff. I'm using Enigmail 2.0.6.1 which Patrick sent me > on a TB 60 beta 7. I would've expected it to require a particular version of mozilla-central, but sure, can try that. (In reply to Patrick Brunschwig from comment #16) > Which version of Enigmail did you try? 2.0.6.1 or a nightly build? I tried > to implement a workaround in the nightly build which seems to work sometimes. I have 2.0.6.1 afaict. > STR: would be > 1. install both Enigmail & Cardbook > 2. open the preferences window in Enigmail (menu Enigmail > Preferences) Hmm, I couldn't repro with those...
(In reply to Emilio Cobos Álvarez [:emilio] from comment #18) > (In reply to Jorg K (GMT+2) from comment #17) > > You can build beta just as you can build trunk, I assume, without having > > tried it. Check out M-C, create a comm/ directory, check out C-B into that. > > Create a .mozconfig with |ac_add_options --enable-application=comm/mail| and > > all the other usual stuff. I'm using Enigmail 2.0.6.1 which Patrick sent me > > on a TB 60 beta 7. > I would've expected it to require a particular version of mozilla-central, > but sure, can try that. Sorry, typo: Check out M-B, mozilla-beta, ..., and put comm-beta into the comm/ subdirectory.
Blocks: 1468377
I managed to repro this on stock thunderbird debug beta, but not trunk for some reason... I'll give a shot at building comm-beta.
Assignee: nobody → emilio
So I took the following m-b revision: https://hg.mozilla.org/releases/mozilla-beta/rev/728f6001d25ca6a9daf6779f833fe4b683d49945 And the following c-b revision: https://hg.mozilla.org/releases/comm-beta/rev/8fa44ae05dddb52941a42706aac2690d0ede4e3e And things are not quite working, and I can't install the add-ons. My mozconfig looks like: mk_add_options AUTOCLOBBER=1 ac_add_options --enable-application=comm/mail export MOZILLA_OFFICIAL=1 export MOZ_DEBUG_SYMBOLS=1 MOZ_ADDON_SIGNING=0 MOZ_REQUIRE_ADDON_SIGNING=0 ac_add_options --enable-debug Jorg, am I missing something?
Flags: needinfo?(jorgk)
Thanks for the persistence ;-) You want to build TB 60 beta using C-B and M-B, right? With the changesets above you would have built TB 61 beta. Sorry, I didn't tell you that we're doing a heap of branch tricks, so please do this: On M-B: hg up THUNDERBIRD_60_VERBRANCH an on C-B: hg up BETA_60_CONTINUATION, see: https://hg.mozilla.org/releases/comm-beta/rev/cf5a7948605c2eefc86d1d9ccc6a8f08534fb6be As for installing add-ons, I don't know. We have strict checking switched on, so set extensions.strictCompatibility to false.
Flags: needinfo?(jorgk)
Alright, finally got it!
Comment on attachment 8985233 [details] Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match. https://reviewboard.mozilla.org/r/250858/#review257188 ::: commit-message-475ee:3 (Diff revision 2) > +Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match. r?bz > + > +Enigmail is loading a XUL document sheet that is @import-ed in another chrome:// Either "in another chrome:// sheet" or "in other chrome:// sheets" depending on whether there is one @import or many. ::: commit-message-475ee:4 (Diff revision 2) > +Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match. r?bz > + > +Enigmail is loading a XUL document sheet that is @import-ed in another chrome:// > +sheets. How does this cause an origin mismatch?
Attachment #8985233 - Flags: review?(bzbarsky) → review+
FWIW; just got this crash as well, and am also using TB 60.0B7 with EnigMail 2.0.6.1 and CardBook. https://crash-stats.mozilla.com/report/index/61a778e7-b62e-4f45-8eb8-dd9140180614
(In reply to Marco Zehe (:MarcoZ) from comment #27) > FWIW; just got this crash as well, and am also using TB 60.0B7 with EnigMail > 2.0.6.1 and CardBook. > https://crash-stats.mozilla.com/report/index/61a778e7-b62e-4f45-8eb8- > dd9140180614 engimail announced 2.0.7 yesterday which should avoid the enigmail case
Comment on attachment 8985233 [details] Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match. https://reviewboard.mozilla.org/r/250858/#review257248 ::: commit-message-475ee:4 (Diff revision 2) > +Bug 1423895: Don't use the XUL stylesheet cache if the parsing mode doesn't match. r?bz > + > +Enigmail is loading a XUL document sheet that is @import-ed in another chrome:// > +sheets. Servo derives the `Origin` of the stylesheet from the parsing mode: https://searchfox.org/mozilla-central/rev/40577076a6e7a14d143725d0288353c250ea2b16/servo/ports/geckolib/glue.rs#1161
Pushed by ecoal95@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a165a02849d3 Don't use the XUL stylesheet cache if the parsing mode doesn't match. r=bz
https://hg.mozilla.org/mozilla-central/rev/a165a02849d3
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Sounds like we want to backport this to Beta/ESR60?
status-firefox59: fix-optional → wontfix
status-firefox60: --- → wontfix
status-firefox61: --- → affected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → affected
Flags: needinfo?(emilio)
I don't think we need to backport it to Firefox's branches since legacy addons that can load chrome sheets are the ones that can trigger this afaict, but Jorg can confirm and do any backport request as needed. As risk assessment, the risk is really low, it only prevents us from using a cached stylesheet in cases we'd otherwise crash.
Flags: needinfo?(emilio)
For comment 32 / comment 33.
Flags: needinfo?(jorgk)
Yes, I'll take it to our release branches for TB 60 beta/ESR. Thanks for the heads-up. Leaving the NI here so I won't forget.
(In reply to Jorg K (GMT+2) from comment #35) > Yes, I'll take it to our release branches for TB 60 beta/ESR. Thanks for the > heads-up. Leaving the NI here so I won't forget. That's going to happen soon.
Flags: needinfo?(jorgk)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: