Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parking_lot_core::parking_lot::HashTable::new crash in [@ <T>::from_entropy::{{closure}}] #175

Closed
cpeterso opened this issue Sep 26, 2019 · 2 comments

Comments

@cpeterso
Copy link

Firefox on Android and Linux is hitting a rare parking_lot panic (just 590 crash reports over the last six months): https://bugzilla.mozilla.org/show_bug.cgi?id=1584043

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 RNG errors in Firefox on Android and Linux tests when 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, @Manishearth changed Stylo's hashmaps use FNV hash instead of an RNG/cryptographically secure hasher since hashmap DOS is not a problem for browsers:

rust-random/rand#180 (comment)

parking_lot could probably do the same for its 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.

Partial stack trace from a Firefox for Android crash report: https://crash-stats.mozilla.com/report/index/5742d966-7264-4325-90e2-3f0760190926#tab-details

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
...
@Amanieu
Copy link
Owner

Amanieu commented Sep 26, 2019

Have you tried upgrading parking_lot? Newer versions don't use rand any more.

@cpeterso
Copy link
Author

Firefox was using parking_lot 0.8.0 and just updated to 0.9.0 last month, which includes your rand changes. I'll close this bug. Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=1575008

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants