Closed Bug 1754490 Opened 3 years ago Closed 2 years ago

Crash in [@ std::collections::hash::map::impl$81::new::KEYS::__getit | env_logger::Builder::new]

Categories

(Core :: Widget: Win32, defect, P3)

x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr91 --- unaffected
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix

People

(Reporter: gerard-majax, Assigned: cmartin)

References

Details

(Keywords: crash, Whiteboard: [win:stability])

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/766cc726-b698-4354-8576-2f7310220209

MOZ_CRASH Reason: couldn't generate random bytes: Access is denied. (os error 5)

Top 10 frames of crashing thread:

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:91
2 xul.dll core::ops::function::Fn::call<void  ../02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/ops/function.rs:227
3 xul.dll std::panicking::rust_panic_with_hook ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:610
4 xul.dll std::panicking::begin_panic_handler::closure$0 ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:502
5 xul.dll std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure$0, never$> ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/sys_common/backtrace.rs:139
6 xul.dll std::panicking::begin_panic_handler ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:498
7 xul.dll core::panicking::panic_fmt ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/core/src/panicking.rs:107
8 xul.dll std::collections::hash::map::impl$81::new::KEYS::__getit ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/thread/local.rs:312
9 xul.dll static env_logger::Builder::new third_party/rust/env_logger/src/lib.rs:406

This seems to be a variation of bug 1751094, but this time on the parent process, so I doubt the sandboxing that was the reason in bug 1751094 applies.

Set up a Windows 7 32 bits VM, installed nightly as well as 98.0b2 from our website, it's working.

Not sure how much it is reliable, but hacking a nightly with bcryptprimitives.dll being added to the WindowsDllBlockListDefs.in reproduces something similar, starting firefox fails very quickly with a stack that looks similar and also mentions the same rust error from random generator, with access denied. So it might hint that this is because somehow this library is failing to load on some system.

I'm not sure there's really more I can do with my windows knowledge, I'll let toshi see what can be done there.

Assignee: lissyx+mozillians → nobody
Flags: needinfo?(tkikuchi)
Component: General → Widget: Win32
Priority: -- → P3
Whiteboard: [win:stability]

Opened an issue in the upstream.

Flags: needinfo?(tkikuchi)
Assignee: nobody → cmartin
Status: NEW → ASSIGNED

Chris, I'm assuming this bug can be closed?

Severity: S2 → S3
Flags: needinfo?(cmartin)

This bug should be fixed due to upstream changes to the Rust std library

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(cmartin)
Resolution: --- → FIXED

Note that as of Rust 1.66(?) this part of the Rust standard library has changed again, with RtlGenRandom being re-removed — although apparently in a different way which should hopefully avoid the issues we've seen here.

Still, we should probably keep watch for regressions when we upgrade rustc.

You need to log in before you can comment on or make changes to this bug.