Rusti crashes on my system when I type "let mut a = 4;" into it.

[vi]

$ rusti
WARNING: The Rust REPL is experimental and may be
unstable. If you encounter problems, please use the
compiler instead. Type :help for help.
rusti> 2+2
4
rusti> fn qqq() -> int { let mut q = 3; q}
rusti> qqq()
3
rusti> let mut q = 3;
Segmentation fault

Rust is e95fcfa .
uname -a -> Linux vi-notebook 3.8.3 #12 SMP Thu Apr 4 15:08:07 FET 2013 i686 GNU/Linux

[alexcrichton]

So it turns out that this is a fairly subtle problem.

When generating JIT code, we also generate glue code for destroying things like @ boxes. Let's say that some of these @ boxes are circularly referenced, so they're left up to the annihilator to clean up. This means that the annihilator will run the glue drop code at task exit time.

What this means is that the drop glue which must get invoked is stored off in JIT memory away from the actual main program. Let's then assume that being a responsible individual, you free your LLVM resources as soon as you're done using them (basically when the JIT code finishes). You can then quickly see how this becomes a problem. If the JIT code is deallocated, then when task exit comes around and tries to run the drop glue... segfault!

To illustrate this, here's a minimal program:

struct A { a: Option<@mut A> }

fn main() {
    let a = @mut A { a: None };
    a.a = Some(a);
}

Note the circular reference to force the box to stay alive until the annihilator runs. Now running this code in the JIT:

$ rustc -Z jit jit.rs
zsh: segmentation fault  rustc -Z jit jit.rs

So what this means is that immediately after _rust_main returns from the jit, we can't destroy the execution engine/llvm context. These two objects shouldn't be leaked, but they should definitely outlive the lifetime of the task that the jit code is executing on. Now this also means that you can't just squirrel them away into TLS. TLS is apparently destroyed before annihilation, so you wind up with the same problem. Somehow the LLVM context/execution engine needs to be communicated back up to the parent task (unless this is the root task in which case I'm not 100% sure how to proceed... Currently this is never the case).

I'll get a patch for this soon.