Bug 2272267
| Summary: | glib v0.19.3 test suite segfaults when built with optimizations | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fabio Valentini <decathorpe> |
| Component: | rust-glib | Assignee: | Rust SIG <rust-sig> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | amulhern, decathorpe, igor.raits, jistone, rust-sig, TicoTimo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | rust-glib-0.19.3-2.fc39 rust-glib-0.19.3-2.fc40 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: |
If this bug requires documentation, please select an appropriate Doc Type value.
|
|
| Last Closed: | 2024-04-12 01:14:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Fabio Valentini
2024-03-29 23:24:07 UTC
(In reply to Fabio Valentini from comment #0) > 1. system rustc (1.77.0 on Fedora 39): > > a. "/usr/bin/cargo test --release -- --skip structured_log": crashes > b. "cargo +system test --release -- --skip structured_log": passes (system = > linked toolchain at /usr) > > (I have *no idea* how case 1.a and 1.b can behave differently.) Is your `rustup default` also "system"? Because 1.a will still use "rustc" from your PATH, which will probably go through the rustup shim again. > I cannot determine why the Fedora Rust toolchain seems to have introduced > this issue with Rust 1.76, whereas upstream rust toolchains only start > exhibiting it with Rust 1.78.0 beta. I think there is UB, and I would not try to reason about the compiler beyond that. Any subtle difference in the toolchains could change optimization in a way that may or may not manifest in noticeably bad behavior. There's an unsafe block in variant_iter.rs: unsafe { let p: *mut libc::c_char = std::ptr::null_mut(); let s = b"&s\0"; ffi::g_variant_get_child( self.variant.to_glib_none().0, i, s as *const u8 as *const _, &p, std::ptr::null::<i8>(), ); let p = std::ffi::CStr::from_ptr(p); p.to_str().unwrap() } The first p is initialized to null_mut(), but it is not itself mutable. It is passed immutably as &p to the FFI call, and then passed to CStr::from_ptr. By Rust semantics, it must still be null! But clearly this code expects g_variant_get_child to have filled in a valid pointer. You can get a fun demonstration of UB here too. I added an assertion before the CStr::from_ptr call: assert_ne!(p, std::ptr::null_mut()); and it fails in a confusing way: thread 'variant_iter::tests::test_variant_iter_array' panicked at glib/src/variant_iter.rs:129:13: assertion `left != right` failed left: 0x7f1fa80011b0 right: 0x0 The fix is to start with "let mut p" and pass "&mut p" to g_variant_get_child. With that, all tests pass in release mode for me on F39 +system, +stable, +beta, and +nightly. Thank you for the pointers! I submitted the suggested fix as a PR to upstream: https://github.com/gtk-rs/gtk-rs-core/pull/1343 FEDORA-2024-f8adb1bac8 (rust-glib0.15-0.15.12-5.fc40, rust-glib0.17-0.17.10-3.fc40, and 2 more) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f8adb1bac8 FEDORA-2024-3ee122ae90 (rust-glib0.15-0.15.12-5.fc38 and rust-glib0.17-0.17.10-3.fc38) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ee122ae90 FEDORA-2024-ec54a6adea (rust-glib0.15-0.15.12-5.fc39, rust-glib0.17-0.17.10-3.fc39, and 2 more) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ec54a6adea FEDORA-2024-3ee122ae90 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-3ee122ae90` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ee122ae90 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-f8adb1bac8 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f8adb1bac8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f8adb1bac8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-ec54a6adea has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-ec54a6adea` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ec54a6adea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-3ee122ae90 (rust-glib0.15-0.15.12-5.fc38 and rust-glib0.17-0.17.10-3.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-ec54a6adea (rust-glib0.15-0.15.12-5.fc39, rust-glib0.17-0.17.10-3.fc39, and 2 more) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-f8adb1bac8 (rust-glib0.15-0.15.12-5.fc40, rust-glib0.17-0.17.10-3.fc40, and 2 more) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. |