What is an example of Rust code that causes a segfault?

Question

I Googled some segfault examples in Rust, but none of crash now. Is Rust able to prevent all segfaults now? Is there a simple demo that can cause a segfault?

Answer 1

If unsafe code is allowed, then:

fn main() {
    unsafe { std::ptr::null_mut::<i32>().write(42) };
}

results in:

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 1.37s
     Running `target/debug/playground`
timeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11:     7 Segmentation fault      timeout --signal=KILL ${timeout} "$@"

as seen on the playground.

---

Any situation that would trigger a segfault would require invoking undefined behavior at some point. The compiler is allowed to optimize out code or otherwise exploit the fact that undefined behavior should never occur, so it's very hard to guarantee that some code will segfault. The compiler is well within its rights to make the above program run without triggering a segfault.

As an example, the code above when compiled in release mode results in an "Illegal instruction" instead.

---

If unsafe code is not allowed, see How does Rust guarantee memory safety and prevent segfaults? for how Rust can guarantee it doesn't happen as long as its memory safety invariants aren't violated (which could only happen in unsafe code).

Don't use unsafe code if you can avoid it.

Answer 2

Strictly speaking, it is always possible to trick a program into thinking that it had a segmentation fault, since this is a signal sent by the OS:

use libc::kill;
use std::process;

fn main() {
    unsafe {
        // First SIGSEGV will be consumed by Rust runtime
        // (see https://users.rust-lang.org/t/is-sigsegv-handled-by-rust-runtime/45680)...
        kill(process::id() as i32, libc::SIGSEGV);
        // ...but the second will crash the program, as expected
        kill(process::id() as i32, libc::SIGSEGV);
    }
}

Playground

This is not really an answer to your question, since that's not a "real" segmentation fault, but taking the question literally - Rust program can still end with a "segmentation fault" error, and here's a case which reliably triggers it.

Answer 3

If you're looking more generally for something that will dump core, and not specifically cause a segfault, there is another option which is to cause the compiler to emit an UD2 instruction or equivalent. There's a few things which can produce this:

• An empty loop without any side effects is UB because of LLVM optimizations:

  fn main() {
       (|| loop {})()
  }
  

  Playground.

  This no longer produces UB.

• Trying to create the never (!) type.

  #![feature(never_type)]
  union Erroneous {
       a: (),
       b: !,
  }
  
  fn main() {
       unsafe { Erroneous { a: () }.b }
  }
  

  Playground.

• Or also trying to use (in this case match on) an enum with no variants:

  #[derive(Clone, Copy)]
  enum Uninhabited {}
  
  union Erroneous {
       a: (),
       b: Uninhabited,
  }
  
  fn main() {
       match unsafe { Erroneous { a: () }.b } {
           // Nothing to match on.
       }
  }
  

  Playground.

• And last, you can cheat and just force it to produce a UD2 directly:

  #![feature(asm)]
  fn main() {
       unsafe {
           asm! {
               "ud2"
           }
       };
  }
  

  Playground

  Or using llvm_asm! instead of asm!

  #![feature(llvm_asm)]
  fn main() {
       unsafe {
           llvm_asm! {
               "ud2"
           }
       };
  }
  

  Playground.

Answer 4

NULL pointer can cause segfault in both C and Rust.

union Foo<'a>{
    a:i32,
    s:&'a str,
}
fn main() {
    let mut a = Foo{s:"fghgf"};
    a.a = 0;
    unsafe {
        print!("{:?}", a.s);
    }
}