Crash in [@ std::io::stdio::_eprint]
Categories
(Core :: mozglue, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox76 | - | --- |
People
(Reporter: mccr8, Unassigned)
References
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-69496e73-e772-41ae-818d-9ca350200318.
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::io::stdio::_eprint src/libstd/io/stdio.rs:811
7 libxul.so fluent_bundle_add_resource intl/l10n/rust/fluent-ffi/src/bundle.rs:254
8 libxul.so mozilla::dom::FluentBundle_Binding::addResource dom/bindings/FluentBinding.cpp:1000
9 libxul.so bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3205
The crash report annotations for Rust MOZ_CRASH seem to be messed up. For this report, it is 'failed printing to stderr: Broken pipe (os error 32)'. I've seen some similar ones in another language.
This doesn't seem like it is a regression, as I found a similar crash with something in 71: bp-f6c971b4-7037-4ba2-a642-34c420200316
Though it is a bit strange that there are a couple of crashes on 71, and then about 15 on 76, and nothing on versions in between.
| Reporter | ||
Comment 1•5 years ago
|
||
[Tracking Requested - why for this release]: possible regression in crash report annotations for Rust crashes, which will make it more difficult to investigate any crashes we see.
Comment 2•5 years ago
|
||
Though it is a bit strange that there are a couple of crashes on 71, and then about 15 on 76, and nothing on versions in between.
This could be explained if there was some eprint that was in 71, then was removed in 72, and fluent added it back in 76.
Comment 3•5 years ago
|
||
It's not a problem with the annotation fortunately; what's happening is that Rust standard print functions abort on certain errors. See bug 1622732 for another example of this. The fix there was to use error!() instead but I'm not sure if that's appropriate here.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
The crash has gone away from nightly as the eprintln!() statement that caused it was removed in bug 1623778. I suggest dup'ing against that bug.
Comment 5•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
| Reporter | ||
Updated•5 years ago
|
Description
•