2059047 - Firefox 153.0 tab crash on Burmese Wikipedia search results page for သ..

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Yorwba]

Attachment: Crash trigger.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

• Go to https://my.wikipedia.org/w/index.php?search=%E1%80%9E..&title=%E1%80%A1%E1%80%91%E1%80%B0%E1%80%B8:%E1%80%9B%E1%80%BE%E1%80%AC%E1%80%96%E1%80%BD%E1%80%B1%E1%80%9B%E1%80%94%E1%80%BA&ns0=1

• Click the search input box on the page containing သ..

Actual results:

• Tab crashes. This does not happen with other input boxes on the same page, nor for search strings not starting with သ or that have more dots.

Expected results:

• It shouldn't have crashed for သ.. either.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, but is not confident enough to move the bug to that component.

Comment 2

[Andre Klapper]

Cannot reproduce, no problem here.

Please follow https://support.mozilla.org/en-US/kb/troubleshoot-firefox-crashes-closing-or-quitting and provide a Crash ID.

Comment 3

[Yorwba]

I updated to 153.0.1, created a new profile, restarted in Troubleshooting mode, and it still reproduces 100% for me.

Here are some crash-stats links with the crash IDs:

https://crash-stats.mozilla.org/report/index/bp-0c04ef3e-ff41-480c-b4bc-1035d0260730
https://crash-stats.mozilla.org/report/index/bp-949e8258-04b3-4702-83d3-5976f0260730
https://crash-stats.mozilla.org/report/index/bp-13b9fe45-e739-4228-98ae-fea520260730
https://crash-stats.mozilla.org/report/index/bp-d1529a3d-d777-41a3-a540-45f780260730
https://crash-stats.mozilla.org/report/index/bp-136a3937-169f-4bc3-8d33-75ea20260730

Comment 4

[Hackbot]

This isn't frontend code — the crash IDs are a Rust bounds-check panic (SmallVec index) inside the vendored ICU4X collator, reached from JS:

icu_collator::elements::CollationElements::look_ahead ← …::next (elements.rs:2082) ← CollatorBorrowed::compare_utf16 ← mozilla_collator_glue_collator_compare_utf16 (js/src/builtin/intl/collator_glue/src/lib.rs:367) ← js::intl::CompareStrings (js/src/builtin/intl/Collator.cpp:707). I.e. Intl.Collator/localeCompare from the page's search-suggestion sorting, with the Burmese (my) tailoring.

Suspected root cause, in third_party/rust/icu_collator/src/elements.rs:

• look_ahead() (1516-1540) documents the assumption that pos grows one-by-one alongside self.upcoming, and its guards are equality only (pos + 1 == len, pos == len). Any pos > len silently falls through to line 1538 self.upcoming[pos] and panics — that's the crashing frame.
• In next(), the lookahead cursor looked_ahead (declared 1962, outside 'outer) is never rebased when upcoming shrinks beneath it: line 2478 self.upcoming.drain(..drain_from_upcoming), and then at 2492-2500 the may_have_contracted_starter path resets drain_from_upcoming = 0 but leaves looked_ahead stale, collect_combining() (2499) consumes more of upcoming, and control re-enters via continue 'outer (2458) → 'ce32loop → 2082 look_ahead(looked_ahead). With the iterator already exhausted (သ + two dots + end of input) look_ahead cannot refill, so pos > upcoming.len() → OOB. This fits the reported specificity: U+101E has no special ce32 in the root data but occurs inside the Burmese tailoring's contraction contexts, and the trailing-.-then-EOF shape is what leaves upcoming short.

Proposed fix (two parts):

1. Correctness: rebase the cursor wherever upcoming is mutated — looked_ahead -= drain_from_upcoming after the drain at 2478, and looked_ahead = 0 alongside drain_from_upcoming = 0 at 2498; audit the in-place upcoming.remove(looked_ahead + i) calls (2129/2134/2151/2156) the same way.
2. Hardening: make look_ahead non-panicking — pos >= self.upcoming.len() instead of ==, and self.upcoming.get(pos).cloned(), so a state-machine slip degrades to mis-ordering rather than a web-content-triggerable content-process crash. Line 2466-2469 has a second unchecked self.upcoming[i] with the same "by construction" comment.

The crate is vendored from hsivonen/icu4x branch gecko (intl/update-icu4x.sh; icu_collator 2.1.1 + 2.3-track changes), so the real fix belongs upstream and should ride a re-vendor, or land temporarily under intl/icu4x-patches/.

Regressed by bug 1937541 ("Migrate collation to ICU4X", f3c156092dba) — new in 153. Note that changeset also routes Places, mozStorage, XSLT sorting and IndexedDB keys through the same collator, so the same panic looks reachable in the parent process; suggest S2 and moving this to Core :: Internationalization (hsivonen) rather than Firefox :: General.

Verification anchors: js/src/tests/non262/Intl/Collator/ (compare.js, collation.js; the migration added root.js/chinese.js/dari.js/…) — a my-locale case belongs there; intl/components/gtest/TestCollator.cpp; upstream third_party/rust/icu_collator/tests/tests.rs.

(Analysis is from reading the source only — not built or run.)

This is an automated analysis result. If this result is incorrect please add a needinfo and feel free to correct the error.

Comment 5

[BugBot [:suhaib / :marco]]

:hsivonen, since you are the author of the regressor, bug 1937541, could you take a look?

For more information, please visit BugBot documentation.

Comment 6

[Yorwba]

The info that this code path is reachable from JavaScript via Intl helped me narrow down the possible call sites. Here's a pure-JS minimal reproduction:

new Intl.Collator("my").compare("", "\u102d\u102f\u1037")

While trying to highlight the search suggestion "သန်လျင်မြို့", Wikipedia extracts all possible length-3 substrings to compare against the query, and one of them happens to be this sequence of combining marks that causes a crash even when comparing against the empty string.

Comment 7

[Yorwba]

I filed an upstream bug report: https://github.com/unicode-org/icu4x/issues/8296

Comment 8

[Henri Sivonen (:hsivonen)]

Thanks. I'll take a look.

Comment 9

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1937541

Comment 10

[Henri Sivonen (:hsivonen)]

Attachment: Bug 2059047 - Reset looked_ahead when resetting drain_from_upcoming.

Upstream issue: https://github.com/unicode-org/icu4x/issues/8296

Comment 12

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f85227cec4be
https://hg.mozilla.org/integration/autoland/rev/bbb405c98969
Reset looked_ahead when resetting drain_from_upcoming. r=dminor

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/bbb405c98969

Comment 15

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:hsivonen, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox155 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.