1624253 - Crash in [@ std::thread::local::fast::Key<T>::try_initialize]

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect, P2)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

This bug is for crash report bp-b1883d7c-67e6-4790-a8c1-f46800200322.

Top 10 frames of crashing thread:

0 libxul.so RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 libxul.so mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 libxul.so core::ops::function::Fn::call src/libcore/ops/function.rs:72
3 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:475
4 libxul.so rust_begin_unwind src/libstd/panicking.rs:375
5 libxul.so std::panicking::begin_panic_fmt src/libstd/panicking.rs:326
6 libxul.so std::thread::local::fast::Key<T>::try_initialize src/libstd/thread/local.rs:424
7 libxul.so rand::rngs::thread::thread_rng third_party/rust/rand/src/rngs/thread.rs:81
8 libxul.so uuid::v4::<impl uuid::Uuid>::new_v4 
9 libxul.so mdns_service_generate_uuid media/mtransport/mdns_service/src/lib.rs:617

I'm not sure if this is the right component because the Rust panic is happening at a lower level. Anyway we're failing here:

https://hg.mozilla.org/mozilla-central/annotate/c4d2ca8f78b7680dc0b199a2cb0e2c6f18cd8963/media/mtransport/mdns_service/src/lib.rs#l617

Because the Rust standard lib can't access an RNG, the panic reason is:

could not initialize thread_rng: getrandom: unknown code 0x0000000D

So maybe we need an upstream fix.

Comment 1

[Dan Minor [:dminor]]

We should probably switch over to using nsIUUIDGenerator for this, for consistency with the rest of Firefox.

Comment 2

[Dan Minor [:dminor]]

Trying to use nsIUUIDGenerator in NrIceCtx fails with NS_ERROR_FACTORY_NOT_REGISTERED, which is probably why I went with the Rust implementation in the first place.

Comment 3

[Dan Minor [:dminor]]

Attachment: Bug 1624253 - Catch panic in mdns_service_generate_uuid; r=mjf!

In rare cases, the random number generator can fail to initialize when
generating a v4 UUID, causing a panic and crash. This adds code to catch that
panic and return a nil (all zeros) UUID instead. Using a nil UUID seems better
from a user privacy perspective than failing to obfuscate the host address and
leaking it when it is expected to be hidden.

Longer term, we might want to switch over to using nsIUUIDGenerator, but that
would require changes to how the socket process is initialized.

Comment 4

[Dan Minor [:dminor]]

Try job here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b80fd1915247a93f206f33422b00095989fda8ca

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4243cef79485
Catch panic in mdns_service_generate_uuid; r=mjf

Comment 7

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/4243cef79485

Comment 8

[Ryan VanderMeulen [:RyanVM]]

AFAICT, this crash was Nightly-only and can ride the trains. Let me know if this needs uplift, though.