nightly (Windows): RustDDS participant event loop null-pointer dereference aborts the `dora-ros2-bridge` test process

[phil-opp]

nightly (Windows): RustDDS participant event loop hits a null-pointer dereference and aborts the dora-ros2-bridge test process

Summary

Test (windows-latest) in the nightly has failed every night from 08-05 to
08-09. The cause is a non-unwinding panic — a null-pointer dereference —
inside RustDDS's participant event loop, which aborts the whole test process
partway through dora-ros2-bridge's lib tests.

Because it is non-unwinding, it cannot be caught: the process dies and the
remaining tests never run.

Failure

running 21 tests
test _core::sequence::tests::owned_seq_empty_drop_is_safe ... ok
...
test transport::zenoh::compatibility::tests::compatibility_humble_topic_identity_uses_unsupported_hash_literal ... ok
thread 'RustDDS Participant 0 event loop' (7364) panicked at
  C:\Users\runneradmin\.cargo\registry\src\index.crates.io-...
null pointer dereference occurred
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.
error: test failed, to rerun pass `-p dora-ros2-bridge --lib`

Run 31299869856, job 93210812014. Reproduced on all five nightlies 08-05 → 08-09,
so it is deterministic rather than flaky.

Notes

• The workspace is still on the pinned rustdds = "=0.11.4"
  (libraries/extensions/ros2-bridge/Cargo.toml:28), so this is not fallout
  from a version bump — feat(ros2-bridge): port to ros2-client 0.10.1 and RustDDS 0.14 #2854 (ros2-client 0.10 / RustDDS 0.13.1) has not landed.
• That pin exists because 0.11.5+ pulls pnet, which breaks Windows builds
  (using pnet may break builds Atostek/RustDDS#375) — see chore(deps): lift rustdds =0.11.4 pin + bump ros2-client once RustDDS#375 is fixed #2450. So the obvious remedy (upgrade) is the thing
  currently blocked, and this issue is a second, independent reason to want off
  0.11.4 on Windows.
• Distinct from ros2-bridge: empty message types (std_msgs/Empty) panic the CDR->Arrow deserializer and kill the DDS participant #2804 (zero-field message types poisoning the DDS cache mutex),
  which was fixed by fix(ros2-bridge): don't panic on zero-field message types (std_msgs/Empty) #2864. Different mechanism, different symptom.

What would help

The log does not name the RustDDS source line — the registry path is truncated in
the excerpt. A run with RUST_BACKTRACE=1 on the Windows nightly job would pin
the frame and make this reportable upstream. That seems like the cheapest next
step before deciding between upgrading (blocked on #2450) and gating the affected
tests off Windows.

Related

• Nightly regression since 2026-07-17 #2742 (nightly regression tracker) — this is one of the three persistent
  failures as of 08-09.
• chore(deps): lift rustdds =0.11.4 pin + bump ros2-client once RustDDS#375 is fixed #2450 — the pin this depends on.
• feat(ros2-bridge): port to ros2-client 0.10.1 and RustDDS 0.14 #2854 — the ros2-client 0.10 / RustDDS 0.13.1 port, still open.

---

Filed from an automated repo watch on 2026-08-09; root-caused from the job log.