parking_lot_core::parking_lot::HashTable::new crash in [@ <T>::from_entropy::{{closure}}]
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox69 | --- | wontfix |
| firefox70 | --- | fixed |
People
(Reporter: cpeterson, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-5742d966-7264-4325-90e2-3f0760190926.
MOZ_CRASH Reason (Raw)
FromEntropy::from_entropy() failed: All entropy sources failed (permanently unavailable); cause: OS RNG not yet seeded (not ready yet); cause: Try again (os error 11)
We've seen similar Android RNG errors in Fennec tests long ago when Fennec was unable to open /dev/urandom because we hit some fd limit. 95% of these crash reports are from Android. 5% are from Linux.
To avoid Windows RNG error crashes, Manish changed Stylo's hashmaps use FNV hash instead of an RNG/cryptographically secure hasher since hashmap DOS is not a problem for browsers:
https://github.com/rust-random/rand/issues/180#issuecomment-337983986
We could probably do the same for parking_lot's HashTables. We probably don't have enough threads in the parking_lot for hashtable DOS to be a risk. Threads are heavier weight than a big hashtable.
OTOH, if the OS RNG is failing in parking_lot code and we sidestep this panic, some other code will probably fail reading the OS RNG soon after.
Top 11 frames of crashing thread:
0 libxul.so GeckoCrash toolkit/xre/nsAppRunner.cpp:5162
1 libxul.so gkrust_shared::panic_hook toolkit/library/rust/shared/lib.rs:246
2 libxul.so core::ops::function::Fn::call src/libcore/ops/function.rs:69
3 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:478
4 libxul.so std::panicking::continue_panic_fmt src/libstd/panicking.rs:381
5 libxul.so std::panicking::begin_panic_fmt src/libstd/panicking.rs:336
6 libxul.so <R as rand::FromEntropy>::from_entropy::{{closure}} hg:hg.mozilla.org/releases/mozilla-beta:third_party/rust/parking_lot_core/<::std::macros::panic macros>:fbd37d14e8976c336816d21137e8239811265630:8
7 libxul.so parking_lot_core::parking_lot::HashTable::new src/libcore/result.rs:764
8 libxul.so parking_lot_core::parking_lot::ThreadData::new third_party/rust/parking_lot_core/src/parking_lot.rs:143
9 libxul.so parking_lot::raw_rwlock::RawRwLock::lock_upgradable_slow third_party/rust/parking_lot/src/raw_rwlock.rs:740
10 libxul.so style::rule_tree::StrongRuleNode::ensure_child servo/components/style/rule_tree/mod.rs:1152
...
|
||
Comment 1•5 years ago
|
||
I wonder why all crashes on Android are Focus. Emilo, any insights on this?
|
Reporter | |
Comment 2•5 years ago
|
||
Perhaps this is a regression in 69? I don't see any crash reports from 68 or earlier over the last 12 months. Fennec is using 68. Focus is using GeckoView 69. Fenix has used GeckoView 68-70, but perhaps this crash is rare enough that none of our Fenix users have hit it yet. Or perhaps they have different types of devices than Focus users.
This crash is pretty rare: just 590 crash reports (all from 69) over the last 12 months.
I filed a bug in parking_lot's issue tracker suggesting they handle the OS RNG errors without panicking:
|
|
Reporter | |
Comment 3•5 years ago
|
||
Curiously, most (68%) of these Android crashes are from Android API level 22 (Android 5.1 Lollipop):
Even though Lollipop accounts for only 3% of all Focus Android crashes (and 5% of Fennec Android crashes):
|
||
Comment 4•5 years ago
|
||
This should be fixed in trunk already, as far as I can tell, by bug 1575008 / https://hg.mozilla.org/mozilla-central/rev/fb816f83f64c.
That removed the problematic rand dependency from parking_lot_core. No idea about why focus is more prominent here in the crash stats.
|
|
||
Comment 5•5 years ago
|
||
I don't think there's anything particularly actionable here, other than maybe uplifting that patch?
|
|
Reporter | |
Comment 6•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
I don't think there's anything particularly actionable here, other than maybe uplifting that patch?
This crash is rare. I don't think we need to bother uplifting bug 1575008.
When we next update Focus to GV 71 Nightly, we can see if bug 1575008 made this crash go away.
|
|
Reporter | |
Comment 7•5 years ago
|
||
Resolving as FIXED because we haven't seen any crash reports with this signature from GV 70+ after bug 1575008 updated parking_lot in Gecko 70.
|
||
Updated•5 years ago
|
Description
•