Startup Crash in [@ std::ffi::os_str::OsString::into_string] for Chinese x86 builds on Windows 7
Categories
(Toolkit :: Telemetry, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox87 | --- | unaffected |
| firefox88 | --- | affected |
| firefox89 | --- | affected |
| firefox90 | --- | affected |
People
(Reporter: aryx, Unassigned)
Details
(Keywords: crash, Whiteboard: [telemetry:fog:m?])
Crash Data
8 crashes so far with Firefox 88.0 (and before on beta)
Crash report: https://crash-stats.mozilla.org/report/index/52d8f0d7-aa53-45fb-9a0c-3961c0210420
Reason: EXCEPTION_ACCESS_VIOLATION_READ
Top 7 frames of crashing thread:
0 xul.dll std::ffi::os_str::OsString::into_string ../cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/ffi/os_str.rs:149
1 xul.dll std::sys_common::backtrace::__rust_begin_short_backtrace<closure-0, tuple<>> ../cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/sys_common/backtrace.rs:125
2 xul.dll core::ops::function::FnOnce::call_once<closure-0, tuple<>> ../cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/ops/function.rs:227
3 xul.dll std::sys::windows::thread::{{impl}}::new::thread_start ../cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/sys/windows/thread.rs:56
4 kernel32.dll BaseThreadInitThunk
5 ntdll.dll __RtlUserThreadStart
6 ntdll.dll _RtlUserThreadStart
|
||
Comment 1•4 years ago
|
||
Emilio, how does the Rust standard lib get upgraded in Gecko builds? Just wondering how we'd begin looking for a culprit for this new crash in 88.
|
||
Comment 2•4 years ago
|
||
It gets updated when rust gets updated. But it's unclear whether this is crashing due to the standard library, this seems more likely to be from the function the new thread invokes... The symbol name has glean::initialize on the stack, which means it is this call, so bug 1698518.
Now why is OsString::into_string crashing with a null deref, I don't know...
|
||
Comment 3•4 years ago
|
||
Yeah, that's the only place we directly call into_string on an OsString.
But an OsString should never be null. I have no idea what's going on there.
I do think this belongs in our component though.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
I wonder, might it be that that unwrap() is failing, because the path is not utf-8, but that code runs soon enough that we don't record the MOZ_CRASH_REASON or something of that sort?
|
|
||
Comment 5•4 years ago
|
||
Yeah, after a second look that was my hunch as well, though I would expect a different error message.
Regardless, we can probably handle that better.
|
|
||
Comment 6•4 years ago
|
||
On a second look: we already expect to get UTF-8 earlier: https://searchfox.org/mozilla-central/rev/9f76a47f4aa935b49754c5608a1c8e72ee358c46/toolkit/components/glean/src/lib.rs#71-78
And because we're dealing with Rust Strings here it should be UTF-8.
So going the roundtrip through a PathBuf and back should not cause a crash.
|
||
Comment 7•4 years ago
|
||
No reports since Fx88. Stopped happening just as mysteriously as it started.
Description
•