Crash in [@ rand::rngs::thread::THREAD_RNG_KEY::__init::{{closure}}]
Categories
(Core :: XPCOM, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | + | fixed |
firefox80 | + | fixed |
firefox81 | + | fixed |
People
(Reporter: pascalc, Assigned: froydnj)
Details
(Keywords: crash)
Crash Data
Attachments
(4 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
|
Details | Review |
This bug is for crash report bp-2c11bc35-8ae6-4c97-853d-4ed260200729.
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:474
4 libxul.so rust_begin_unwind src/libstd/panicking.rs:378
5 libxul.so core::panicking::panic_fmt src/libcore/panicking.rs:85
6 libxul.so rand::rngs::thread::THREAD_RNG_KEY::__init::{{closure}} third_party/rust/rand/src/rngs/thread.rs:65
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 third_party/rust/uuid/src/v4.rs:28
9 libxul.so GkRustUtils_GenerateUUID xpcom/rust/gkrust_utils/src/lib.rs:14
Comment 1•5 years ago
|
||
Looks like we're crashing while generating a UUID? Hopefully this is not a rust bug.
Comment 2•5 years ago
|
||
The crash reason on the report in comment 0 is "could not initialize thread_rng: getrandom: unknown code 0x00000016 -"
Comment 3•5 years ago
|
||
Oh noes, getrandom
+ Linux, that's just what we need! /s
Comment 4•5 years ago
|
||
(That's also the crash reason for all 23 crashes I see for 79.)
Comment 5•5 years ago
|
||
All these crashes except for one happen on API 23. It doesn't look like we collect kernel version info, sadly.
Assignee | ||
Comment 6•5 years ago
|
||
The official Linux kernel 3.14.29 (as suggested by the original crash report) doesn't support the getrandom
syscall, so I would think that we would hit the code here:
https://searchfox.org/mozilla-central/source/third_party/rust/getrandom/src/linux_android.rs#48
but apparently we're not doing that?
I note that our getrandom
crate is kind of old and doesn't include the fix:
https://github.com/rust-random/getrandom/commit/6716ad06a5a1e502b80bd1983308eab655d90b83
Maybe we're running into problems with some argument type (and therefore calling convention) mismatches?
Assignee | ||
Comment 7•5 years ago
|
||
https://github.com/rust-random/getrandom/pull/73 suggests that bad things can happen with the current version of the getrandom
crate.
Assignee | ||
Comment 8•5 years ago
|
||
And indeed https://github.com/torvalds/linux/blob/v5.4/drivers/char/random.c#L2186 would return EINVAL if we had bogus bits set in the upper 32 bits of the argument, and EINVAL is 22 or 0x16, which matches comment 2.
Assignee | ||
Comment 9•5 years ago
|
||
Updating getrandom
is a bit of a mess, but since I've started this, I might as well try and finish it.
Assignee | ||
Comment 10•5 years ago
|
||
[Tracking Requested - why for this release]: Crashes in the new Firefox for Android are not great. It's going to be a biggish patch to update this, but relatively safe.
Assignee | ||
Comment 11•5 years ago
|
||
We need this bump for a couple of reasons:
- It enables floating the libc crate version, which makes keeping up-to-date
with upstream changes easier. - It enables floating the getrandom crate version, which enables updating
getrandom to a version with less buggy behavior around the Linux
getrandom
syscall on some architectures.
We also take this opportunity to sync up our vendored lucet with the lucet
that we use to build things in taskcluster.
Assignee | ||
Comment 12•5 years ago
|
||
As the commit title suggests, this is a manual update, but we need to also
update config/rules.mk
for the changed location of the wasi bindings.
Depends on D85408
Assignee | ||
Comment 13•5 years ago
|
||
We can do this update now that lucet-runtime-internals
no longer pins the
getrandom
crate version; the conflicts around spinlocks have been removed
and the new version of getrandom
brings in an important fix for calling
SYS_getrandom
on some architectures.
Depends on D85409
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/56611f947075
https://hg.mozilla.org/mozilla-central/rev/3f50dac7d0ba
https://hg.mozilla.org/mozilla-central/rev/6d86f8e2824d
Updated•5 years ago
|
Comment 16•5 years ago
|
||
I don't suppose for uplift we can just do the one-line change to getrandom?
Assignee | ||
Comment 17•5 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #16)
I don't suppose for uplift we can just do the one-line change to getrandom?
We could make a fork of the getrandom
crate that pulled in just the syscall fix, if you thought that was more palatable.
Comment 18•5 years ago
|
||
Anything that would improve the likelihood of being able to uplift for a potential 79 dot release for GV would be great, IMHO.
Comment 19•5 years ago
|
||
The patch landed in nightly and beta is affected.
:froydnj, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 20•5 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #19)
The patch landed in nightly and beta is affected.
:froydnj, is this bug important enough to require an uplift?
If not please setstatus_beta
towontfix
.
I think so? (Can't believe I'm asking questions of a bot.)
I'm trying to get a backport of the syscall fix done, and then get at least beta patched (ideally that patch will apply to release as well).
Assignee | ||
Comment 21•5 years ago
|
||
[Tracking Requested - why for this release]: aklotz suggested in comment 18 that we might want to do a dot release for this, so asking for tracking to get an opinion on that.
Assignee | ||
Comment 22•5 years ago
|
||
This patch for beta takes a slightly different approach than the central
fix. Rather than updating all of lucet just to update the getrandom
create, we instead backport the necessary syscall calling fix to the 0.1.3
branch and vendor that backport instead.
Assignee | ||
Comment 23•5 years ago
|
||
Comment on attachment 9167698 [details]
Bug 1655929 - backport the getrandom syscall fix to 0.1.3; r=#build
Beta/Release Uplift Approval Request
- User impact if declined: Weird startup crashes on arm64 devices for Fenix.
We are writing a beta-only (possibly for release as well) patch because this particular patch is much less invasive than the patch that landed on central.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce: We don't have any STR, but it would be fantastic if QE could somehow find STR to reproduce on an arm64 Android device and then verify that this patch fixes those crashes.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): We're just updating a single crate, and in that crate, we're just changing how a particular syscall calling sequence works; there shouldn't (crosses fingers) be any other functional changes happening here.
- String changes made/needed: None
Comment 24•5 years ago
|
||
Comment on attachment 9167698 [details]
Bug 1655929 - backport the getrandom syscall fix to 0.1.3; r=#build
crash fix for fenix; approved for 80.0b4, thanks
Comment 25•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 26•4 years ago
|
||
Comment on attachment 9167698 [details]
Bug 1655929 - backport the getrandom syscall fix to 0.1.3; r=#build
Approved for Fenix 79.0.5.
Comment 27•4 years ago
|
||
bugherder uplift |
Description
•