One Compilation, Three Seconds to Crash: How I Exposed Memory Safety with Rust

💥 It is said that Rust bids farewell to segmentation faults forever, yet I encountered a cargo build crash with SIGSEGV just 3 seconds later.Memory safety? Yes, but it only guarantees “safety” without ensuring “correctness”.Today, this post will dissect the three UB monsters I created with Rust, along with a troubleshooting toolbox, which I recommend saving and sharing to help you avoid detours.

Commit	Phenomenon	Cause
commit 3ea74	`<span>unsafe</span>` dereferencing `<span>*mut T</span>` immediately followed by `<span>free</span>`	Dangling pointer
commit 8c112	`<span>tokio::spawn</span>` closure capturing `<span>&mut self</span>`	Data race
commit 9f5ab	`<span>Vec::set_len</span>` increased by 1, new slot uninitialized	Memory uninitialized

Commonality: All compilations passed, but miri failed all tests.

Key Point 1: Dangling Pointers – A Landmine Beyond the “Safe” Boundary

rust

letmut x =Box::new(42);let p =&mutx asmuti32;drop(x);// Memory has been freedunsafe{*p =0;}// BOOM

✅ Defusal Plan

Use NonNull<T> to mark “potentially invalid” pointers
Add lifetimes 'a and PhantomData to the type to ensure &self lifespan ≥ pointer usage period
If raw pointers are necessary, implement a Drop guard: set the pointer to null in Drop, and check for null in subsequent unsafe blocks

Key Point 2: “Invisible &mut” in Asynchronous Closures

rust

structConn{ buf:[u8;4096]}

implConn{asyncfnread(&mutself){tokio::spawn(asyncmove{self.buf[0]=1;// Compiled, but crashes on run});}}

Issue:&mut self<code> is moved to a new thread by spawn, leading to two &mut existing simultaneously = data race.

✅ Defusal Plan

Extract shared fields into Arc<Mutex<T>> or <code>RwLock
Use message channels (tokio::mpsc) to return “memory modification rights” to a single thread
If zero-copy is desired, use tokio::io::AsyncReadExt::read_buf + Vec<u8> pooling to avoid mutable references across threads

Key Point 3: The “Uninitialized Trap” of Vec::set_len

rust

let mut v = Vec::with_capacity(10);
unsafe { v.set_len(5); }// 0..5 are garbage
v[0] // UB: Reading uninitialized memory

✅ Defusal Plan

Use resize(n, default) or <code>vec![val; n] for safe initialization
If you must call set_len directly, write before expanding: fill new slots using ptr::write, then set_len(old + n)
Run cargo +nightly miri test to set CI gates, catching any uninitialized reads instantly

Troubleshooting Toolbox (Tested End-to-End)

Tool	Scenario	Command Example
miri	Detect UB	cargo +nightly miri test
san	Runtime overflow/out-of-bounds	RUSTFLAGS=”-Z sanitizer=address” cargo test
cargo-asm	View generated assembly	cargo asm –rust
tokio-console	Async scheduling anomalies	`<span>console-subscriber</span>` + `<span>tokio-console</span>`
valgrind	Raw C interaction segmentation faults	valgrind –tool=memhog ./target/debug/app

A Summary Chart: Rust UB Quick Reference

(Save to your phone, review for 10 seconds before writing unsafe code)

Dangling pointer → NonNull + PhantomDataData race → Arc<Mutex> or channelsUninitialized → ptr::write then set_len

Comments Section Open

👇 Share your “safe but crashed” experiences with Rust, and five lucky winners will receive miri stickers + a physical copy of “The Rust Programming Language”, let’s write memory safety into CI and leave crashes in the past!

Memory safety ≠ logical correctness; Rust is not magic, it is a sharper scalpel—don’t cut yourself.

Key Point 1: Dangling Pointers – A Landmine Beyond the “Safe” Boundary

rust

Key Point 2: “Invisible &mut” in Asynchronous Closures

Key Point 3: The “Uninitialized Trap” of Vec::set_len

Troubleshooting Toolbox (Tested End-to-End)

A Summary Chart: Rust UB Quick Reference

Comments Section Open

Related posts

Leave a Comment Cancel reply