Closed Bug 1684880 Opened 4 years ago Closed 1 year ago

Crash in [@ style::gecko_string_cache::WeakAtom::to_ascii_lowercase]

Categories

(Core :: CSS Parsing and Computation, defect)

Unspecified
All
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gsvelto, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/667a102a-dfb5-4927-a734-2d3d60201230

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 xul.dll style::gecko_string_cache::WeakAtom::to_ascii_lowercase servo/components/style/gecko_string_cache/mod.rs:291
1 xul.dll style::selector_map::MaybeCaseInsensitiveHashMap<style::gecko_string_cache::Atom, style::invalidation::stylesheets::InvalidationKind>::try_entry<style::invalidation::stylesheets::InvalidationKind> servo/components/style/selector_map.rs:646
2 xul.dll style::invalidation::stylesheets::StylesheetInvalidationSet::insert_invalidation servo/components/style/invalidation/stylesheets.rs:470
3 xul.dll style::invalidation::stylesheets::StylesheetInvalidationSet::collect_invalidations_for_rule servo/components/style/invalidation/stylesheets.rs:591
4 xul.dll style::stylesheet_set::DocumentStylesheetSet<style::gecko::data::GeckoStyleSheet>::collect_invalidations_for<style::gecko::data::GeckoStyleSheet> servo/components/style/stylesheet_set.rs:396
5 xul.dll style::stylist::Stylist::append_stylesheet servo/components/style/stylist.rs:599
6 xul.dll geckoservo::glue::Servo_StyleSet_AppendStyleSheet servo/ports/geckolib/glue.rs:1659
7 xul.dll mozilla::ServoStyleSet::AppendStyleSheet layout/style/ServoStyleSet.cpp:589
8 xul.dll mozilla::dom::Document::AddAdditionalStyleSheet dom/base/Document.cpp:6843
9 xul.dll nsDOMWindowUtils::AddSheet dom/base/nsDOMWindowUtils.cpp:3459

It seems that this is already happening in release which I find odd since this is the kind of stuff which we should have spotted earlier. The crash appears to be identical on both Windows and Linux.

I found more signatures. We didn't catch this during triage because the volume on nightly was apparently nil. It's happening on macOS too and given the volume just a few months back this was so much below the waterline that it was impossible to spot. Some change has made it visible recently.

Crash Signature: [@ __memcpy_sse2_unaligned_erms | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_ssse3_back | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_ssse3 | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@… → [@ memcpy_repmovs | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_sse2_unaligned_erms | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_ssse3_back | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@…

It seems that release 82 was the first one in which we had a measurable crash volume.

Severity: -- → S2

emilio, do you have any idea about this?

Flags: needinfo?(emilio)

The only memcpy I see is this one, and that code seems sound to me... Maybe we have broken atoms sometimes? But even then, the crash seems to happen when writing to the stack buffer, which seems impossible to me.

This code also hasn't changed in a while, and the only unsafe in it is to convert the pointer in MaybeUninit<[u16; 64]> into a slice, which then isn't moved... Maybe a rust update / llvm issue?

Flags: needinfo?(emilio)

This is much higher volume on Linux than Windows which makes me suspicious: https://crash-stats.mozilla.org/search/?signature=~to_ascii_lower&product=Firefox&date=%3E%3D2020-10-08T13%3A39%3A00.000Z&date=%3C2021-01-08T13%3A39%3A00.000Z&_facets=signature&_facets=install_time&_facets=platform&_sort=-platform&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=install_time#facet-platform

It's possible that the Windows issues are unrelated and just getting mixed into this bucket by chance. The two Windows ones that I looked at had hardware issues, one had a single-bit failure in !chkimg, the other had a single-bit error in the result of a mov reg, reg. Unfortunately I can't debug the Linux ones as effectively.

Let's call this one S3, given comment 5.

(I wonder if the Linux-specific ones are from some distro-specific configuration/patch; if so, that would still be nice to identify & help them with. Still, crash volume seems pretty low, fortunately.)

Severity: S2 → S3

I find it odd that the volume here is larger on Linux than on Windows. If this was due to bad hardware I'd expect the volume to be more tilted towards Windows. However, given we're crashing into a library function it might be that the implementation has an impact on the volume. Anyway here's another signature.

Crash Signature: style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_ssse3 | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ memcpy | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memmove_avx_unaligned_erms | style::gecko_s… → style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_ssse3 | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ __memcpy_avx_unaligned_erms | style::gecko_string_cache::WeakAtom::to_ascii_lowercase] [@ memcpy | style::gecko_st…

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.