Crash in [@ std::collections::hash::map::impl$81::new::KEYS::__getit | env_logger::Builder::new]
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
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.
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
Set up a Windows 7 32 bits VM, installed nightly as well as 98.0b2 from our website, it's working.
Reporter | ||
Comment 2•3 years ago
|
||
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.
Reporter | ||
Comment 3•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Opened an issue in the upstream.
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 5•2 years ago
|
||
Chris, I'm assuming this bug can be closed?
Assignee | ||
Comment 6•2 years ago
|
||
This bug should be fixed due to upstream changes to the Rust std
library
Updated•2 years ago
|
Comment 7•2 years ago
|
||
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.
Description
•