Crash with LTO on aarch64-unknown-linux-gnu

[epgts]

See epgts/rontest@b1fde44#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542 for simple reproduction recipe. Works reliably on amd64, crashes reliably on aarcy64.

Configuration:

• Ubuntu 22.04
• cargo --version --verbose
  • cargo 1.57.0
  • release: 1.57.0
  • host: aarch64-unknown-linux-gnu
  • libgit2: 1.3.0 (sys:0.13.23 vendored)
  • libcurl: 7.81.0 (sys:0.4.49+curl-7.79.1 system ssl:GnuTLS/3.7.3)
  • os: OracleLinux 22.4.0 [64-bit]

Backtrace:

#0  core::fmt::Formatter::alternate () at library/core/src/fmt/mod.rs:1880
#1  core::fmt::Formatter::pad_integral () at library/core/src/fmt/mod.rs:1354
#2  0x0000aaab8aecf5d8 in core::fmt::num::fmt_u128 () at library/core/src/fmt/num.rs:641
#3  0x0000aaab8aecfd2c in core::fmt::write () at library/core/src/fmt/mod.rs:1190
#4  0x0000aaab8aec5ad8 in std::io::Write::write_fmt (self=0xffffffe1dfc8, fmt=...)
    at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/io/mod.rs:1657
#5  0x0000aaab8aec76f0 in <&mut ron::ser::Serializer<W> as serde::ser::Serializer>::serialize_u128 (self=0xffffffe1dfc8, v=0)
    at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/ron-0.7.0/src/ser/mod.rs:409
#6  0x0000aaab8aec7668 in <&mut ron::ser::Serializer<W> as serde::ser::Serializer>::serialize_u64 (self=0xffffffe1dfc8, v=0)
    at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/ron-0.7.0/src/ser/mod.rs:405
#7  0x0000aaab8aec79c4 in serde::ser::impls::<impl serde::ser::Serialize for u64>::serialize (self=0xffffffe1e428,
    serializer=0xffffffe1dfc8) at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.137/src/ser/impls.rs:15
#8  0x0000aaab8aec7874 in <&mut ron::ser::Serializer<W> as serde::ser::Serializer>::serialize_newtype_struct (self=0xffffffe1dfc8,
    name=..., value=0xffffffe1e428) at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/ron-0.7.0/src/ser/mod.rs:506

[juntyr]

Curious ... it seems the problem is in using write!(vec, "{}", i) to write a formatted int to the output ron, which is at this stage a Vec<u8>. Does this crash occur on the latest master branch as well?

[epgts]

Turns out the buggy code is behind a feature after the v0.7.0 tag! What do you think about releasing a 0.7.1 that includes commit 6e96c3b ? Then we can just opt out of that feature until the bug is fixed (if we need it at all...?)

Now I know how you can easily test this yourself:

$ git diff
diff --git a/Cargo.toml b/Cargo.toml
index c5dc835..5ce6e8b 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -33,3 +33,6 @@ serde_bytes = "0.11"
 serde_json = "1"
 bitflags-serial = { git = "https://github.com/kvark/bitflags-serial" }
 option_set = "0.1"
+
+[profile.dev]
+lto = "fat"

$ cargo t --features integer128
[...]
error: test failed, to rerun pass '--lib'

Caused by:
  process didn't exit successfully: `/home/epg/ron/target/debug/deps/ron-26b7af474b8a0104` (signal: 11, SIGSEGV: invalid memory reference)

$ gdb -ex bt target/debug/deps/ron-26b7af474b8a0104 core.*
[...]
#0  core::fmt::Formatter::alternate () at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c//library/core/src/fmt/mod.rs:1880
#1  core::fmt::Formatter::pad_integral () at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c//library/core/src/fmt/mod.rs:1354
#2  0x0000aaac4a6cb6e8 in core::fmt::num::fmt_u128 ()
    at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c//library/core/src/fmt/num.rs:641
#3  0x0000aaac4a6c0f34 in core::fmt::write () at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c//library/core/src/fmt/mod.rs:1190
#4  0x0000aaac4a639e08 in std::io::Write::write_fmt (self=0xfffe9f89c660, fmt=...)
    at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/io/mod.rs:1657
#5  0x0000aaac4a639d90 in std::io::impls::<impl std::io::Write for &mut W>::write_fmt (self=0xfffe9f89c678, fmt=...)
    at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/io/impls.rs:81
#6  0x0000aaac4a70bf70 in ron::ser::Serializer<W>::serialize_uint (self=0xfffe9f89c678, value=0)
    at /home/epg/ron/src/ser/mod.rs:364
#7  0x0000aaac4a70bed8 in <&mut ron::ser::Serializer<W> as serde::ser::Serializer>::serialize_u8 (self=0xfffe9f89c678, v=0)
    at /home/epg/ron/src/ser/mod.rs:424
#8  0x0000aaac4a698d5c in serde::ser::impls::<impl serde::ser::Serialize for u8>::serialize (self=0xfffe9f89cbb8 "\000",
    serializer=0xfffe9f89c678) at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.137/src/ser/impls.rs:15
#9  0x0000aaac4a70e920 in <ron::ser::Compound<W> as serde::ser::SerializeTuple>::serialize_element (self=0xfffe9f89c3c0,
    value=0xfffe9f89cbb8 "\000") at /home/epg/ron/src/ser/mod.rs:816
#10 0x0000aaac4a699190 in serde::ser::impls::<impl serde::ser::Serialize for [T; 16]>::serialize (
    self=0xfffe9f89cbb8 b"\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017", serializer=0xfffe9f89c678)
    at /home/epg/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.137/src/ser/impls.rs:154
#11 0x0000aaac4a6af638 in ron::options::Options::to_string (self=0xfffe9f89cb20,
    value=0xfffe9f89cbb8 b"\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017") at /home/epg/ron/src/options.rs:169
#12 0x0000aaac4a70b2b8 in ron::ser::to_string (value=0xfffe9f89cbb8 b"\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017")
    at /home/epg/ron/src/ser/mod.rs:41
#13 0x0000aaac4a6397a0 in ron::ser::tests::test_byte_stream () at /home/epg/ron/src/ser/tests.rs:119

[juntyr]

Could you perhaps test if

use std::io::Write;

fn main() {
    let mut v = Vec::new();
    write!(v, "{}", 0_u128);
    println!("{}", std::str::from_utf8(&v).unwrap());
}

is enough to trigger the issue on aarcy64?

[torkleyy]

I think the proposed solution can only serve as a workaround, the issue should be fixed in rustc's linker.

[juntyr]

@epgts Does this issue still persist with Rust 1.64 and ron 0.8?