rusti segfaults for trivial programs

[wting]

rustc v0.6:

$ rusti
rusti>  fn foo() { for 5.times { io::println("hi"); } }
[1]    11363 segmentation fault (core dumped)  rusti

$ rusti
rusti> let x = 1;
<anon>:35:4: 35:7 warning: unused variable: `x`
<anon>:35 let x = 1;
              ^~~
[1]    11937 segmentation fault (core dumped)  rusti

I was able to reproduce this today by using ctrl+c to exit rusti. Subsequent rusti runs segfaulted regardless of the statement.

[Blei]

I spent an afternoon debugging this. It causes mysterious crashes inside dlopen() and fascinating invalid reads in valgrind, but in the end it turns out that increasing the C_STACK_SIZE in rust_sched_loop.cpp makes rusti work again (set to 100_1024_1024 here).

My theory (cobbled together using valgrind output) is, that rusti calls into the compiler, which calls into LLVMRustLoadCrate, which calls dlopen(), which in turn reads stuff into a buffer on the c stack and in the process overruns the allocated stack, wreaking general havoc.

Not sure how this can be solved elegantly, or even if my diagnosis is correct.

[thestinger]

It seems like this problem is at least partly solved on OS X, but still exists on Linux.

[z0w0]

Awesome work debugging it, I've been trying to debug it for a long time. I'm not very good at debugging, haha. How can we fix this? Kind of need it fixed before 0.6.

[z0w0]

@brson, @nikomatsakis is there any way to allocate a larger C stack when calling LLVMRustLoadCrate at the moment (without increasing C_STACK_SIZE, which I presume is an unacceptable change)?