bug: Using PkarrPublisher on the macOS platform in release mode causes a segmentation fault

[zormit]

Describe the bug

The segfault described in #2844 came up again. Given it was fixed in v0.31.0, I would assume it's new instance of the same problem.

The bug only appears in Rust version 1.85 and larger. It only appears in a non-debug build (setting debug=true makes the problem disappear).

Relevant Logs

I didn't yet create a nice minimal example as the previous bug author. I am producing as part of our project, ethersync. For example the current main:

% rust-lldb ../target/release/ethersync
<...snip...>
(lldb) type category enable Rust
(lldb) target create "../target/release/ethersync"
Current executable set to 'target/release/ethersync' (x86_64).
(lldb) run share
Process 19359 launched: 'target/release/ethersync' (x86_64)
...
Process 19359 stopped
* thread #11, name = 'tokio-runtime-worker', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010067707d ethersync`_$LT$simple_dns..dns..rdata..RData$u20$as$u20$simple_dns..dns..wire_format..WireFormat$GT$::parse_after_check::h7b3eb1a098c6668c + 5405
ethersync`_$LT$simple_dns..dns..rdata..RData$u20$as$u20$simple_dns..dns..wire_format..WireFormat$GT$::parse_after_check::h7b3eb1a098c6668c:
->  0x10067707d <+5405>: movaps -0xc8(%rbp), %xmm0
    0x100677084 <+5412>: movaps -0xb8(%rbp), %xmm1
    0x10067708b <+5419>: movaps -0xa8(%rbp), %xmm2
    0x100677092 <+5426>: movaps %xmm0, 0x40(%rdi)
Target 0: (ethersync) stopped.
(lldb) bt
* thread #11, name = 'tokio-runtime-worker', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010067707d ethersync`_$LT$simple_dns..dns..rdata..RData$u20$as$u20$simple_dns..dns..wire_format..WireFormat$GT$::parse_after_check::h7b3eb1a098c6668c + 5405
    frame #1: 0x00000001006650da ethersync`_$LT$simple_dns..dns..resource_record..ResourceRecord$u20$as$u20$simple_dns..dns..wire_format..WireFormat$GT$::parse_after_check::h2ce3f8587cf8e2e9 + 330
    frame #2: 0x000000010066ac27 ethersync`simple_dns::dns::packet::Packet::parse_section::he496fd603b66ba0a + 215
    frame #3: 0x000000010066a407 ethersync`simple_dns::dns::packet::Packet::parse::h5770048e7073e337 + 679
    frame #4: 0x0000000100659ee3 ethersync`pkarr::signed_packet::SignedPacket::new::hba03dca34a66db24 + 14371
    frame #5: 0x0000000100656640 ethersync`pkarr::signed_packet::SignedPacketBuilder::sign::h057089b83fc64839 + 80
    frame #6: 0x00000001006565de ethersync`pkarr::signed_packet::SignedPacketBuilder::build::hdc07b6cecbf5e0f4 + 14
    frame #7: 0x0000000100624d57 ethersync`iroh_relay::node_info::NodeInfo::to_pkarr_signed_packet::hcd6e3e8ebd82499e + 1991
    frame #8: 0x00000001002a313b ethersync`_$LT$tracing..instrument..Instrumented$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::he66ca4f258cda682 + 2219
    frame #9: 0x000000010037483e 
(lldb)

Expected behavior

Don't segfault.

Platform(s)
Desktop:

• OS: macOS
• OS Version: 15.5 (24F74)
• Processor: x86_64
• Rust Version 1.85 (it doesn't appear with 1.84!)
• iroh-base v0.35.0
• pkarr v3.7.2

[dignifiedquire]

Thanks for the detailed report.

For reference it appears simple-dns@0.9.3 is being used, and not the latest 0.10 version https://github.com/ethersync/ethersync/blob/main/daemon/Cargo.lock#L4010

[dignifiedquire]

Looking at this in more detail, I wonder if this is a compiler regression. It seems that there is no unsafe code in simple_dns which would excuse such sudden changes in behavior. I currently don't have any x86_64 macs around, so if you can figure out a way to make a minimal repro, I think this should probably should be filed directly with rust as a compiler bug

[zormit]

Yeah I was wondering the same, I also noticed that cargo geiger doesn't find unsafe usages, neither in 0.10 nor 0.9.3.

I wonder how to produce such a minimal example, but I'll see if I can come up with something. I guess closing this bug here might make sense given it's out of the iroh scope, but I'll leave that up to you.

[zormit]

FWIW, I just tried to reproduce with Rust Nightly (rustc 1.90.0-nightly (706f244db 2025-06-23)) and Beta (rustc 1.89.0-beta.1 (390a0ab5d 2025-06-23)) and apparently it's not segfaulting anymore as described above 🤷🏼 Before I just had tried until stable!

I didn't find any obvious issue in the tracker. The closest thing would be rust-lang/rust#117902 but that one is a bit too old and while the symptoms are the same, it's slightly different. It could also have been an upstream LLVM problem, I guess?

For me it's good enough, I'll just compile with Nightly or Beta and wait for the next release :)