Server segfault when passing channels from inner tasks

[jfager]

I'm running into an issue with a basic server where when I pass a channel out of a task spawned for each connection, the server will segfault on subsequent requests. I'm probably doing The Wrong Thing here, but segfaulting from code that's not marked unsafe seems like a bug.

Would also appreciate feedback on the right way to have a task per connection with some way to pump data into it.

Code recreating the issue is at https://gist.github.com/jfager/5788001, gdb backtrace below.

rust: task failed at 'option::unwrap none', /Users/jason/src/rust/src/libstd/option.rs:268
rust: domain main @0x108800010 root task failed
rust: task failed at 'killed', /Users/jason/src/rust/src/libstd/pipes.rs:286  
rust: task failed at 'killed', /Users/jason/src/rust/src/libstd/pipes.rs:286
rust: task failed at 'killed', /Users/jason/src/rust/src/libstd/pipes.rs:286
rust: task failed at 'killed', /Users/jason/src/rust/src/libstd/pipes.rs:286
rust: task failed at 'killed', /Users/jason/src/rust/src/libstd/pipes.rs:286

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 4603 thread 0x1703]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000010098bcf2 in uv__io_poll () at rust_task.cpp:1327
#2  0x000000010097dac8 in uv_run () at rust_task.cpp:1327
#3  0x00000001005a0ba1 in rust_uv_run__c_stack_shim ()
#4  0x000000010097cd51 in __morestack () at rust_task.cpp:1327
#5  0x000000010096d5de in rust_task::call_on_c_stack (this=0x100a0ca20, args=0x1, fn_ptr=0x1) at rust_task.h:484
#6  0x000000010096de0f in upcall_call_shim_on_c_stack (args=0x1055ff0c8, fn_ptr=0x1055fde30) at rust_upcall.cpp:70
#7  0x000000010064d7ee in uv_iotask::spawn_iotask::anon::expr_fn_21659 ()
#8  0x0000000100660722 in uv_global_loop::spawn_loop::anon::anon::anon::expr_fn_23194 ()
#9  0x00000001001c2590 in unstable::weak_task::weaken_task::_633e817ba3eab3b9::_07pre ()
#10 0x0000000100215c2b in __morestack ()

[jdm]

A backtrace from rust_task_fail would be more useful, to see where the option::unwrap none failure is coming from.

[jfager]

I'm having trouble getting a debug build, looks like the same problem as #6814. If you have any guidance on how to get the trace you need, please let me know.

Here's breaking on upcall_fail:

Breakpoint 1, upcall_fail (expr=0x100095eb0 "option::unwrap none", file=0x100095ed0 "/Users/jason/src/rust/src/libstd/option.rs", line=268) at rust_upcall.cpp:126
126             size_t line) {
(gdb) bt
#0  upcall_fail (expr=0x100095eb0 "option::unwrap none", file=0x100095ed0 "/Users/jason/src/rust/src/libstd/option.rs", line=268) at rust_upcall.cpp:126
#1  0x00000001001b7a83 in sys::begin_unwind_::_89e154cd0915671::_07pre ()
#2  0x00000001001b7b52 in sys::__extensions__::fail_with::anon::anon::expr_fn_22379 ()
#3  0x00000001001062a4 in sys::__extensions__::meth_10847::fail_with::_db4c44d01ce4116::_07pre ()
#4  0x0000000100079ca3 in comm::__extensions__::send_9140::_6efa6b5d4827a71::_00 ()
#5  0x000000010006d155 in server::anon::anon::expr_fn_8556 ()
#6  0x000000010009015d in __morestack ()
Previous frame inner to this frame (gdb could not unwind past this frame)
Current language:  auto; currently c++

[jfager]

Sorry, from rust_task_fail like you asked for:

[Switching to process 15175 thread 0x2207]

Breakpoint 1, rust_task_fail (task=0x108000420, expr=0x100095eb0 "option::unwrap none", file=0x100095ed0 "/Users/jason/src/rust/src/libstd/option.rs", line=268) at rust_task.cpp:90
90                 size_t line) {
(gdb) bt
#0  rust_task_fail (task=0x108000420, expr=0x100095eb0 "option::unwrap none", file=0x100095ed0 "/Users/jason/src/rust/src/libstd/option.rs", line=268) at rust_task.cpp:90
#1  0x000000010096ce67 in rust_task::fail (this=<value temporarily unavailable, due to optimizations>, expr=<value temporarily unavailable, due to optimizations>, file=<value temporarily unavailable, due to optimizations>, line=<value temporarily unavailable, due to optimizations>) at rust_task.cpp:328
#2  0x000000010097cd51 in __morestack () at rust_task.cpp:1327
#3  0x000000010096d5de in rust_task::call_on_c_stack (this=0x108000420, args=0x1009a2588,     fn_ptr=0x100095ed0) at rust_task.h:484
#4  0x000000010096e7d6 in upcall_fail (expr=0x100095eb0 "option::unwrap none", file=0x100095ed0 "/Users/jason/src/rust/src/libstd/option.rs", line=268) at rust_upcall.cpp:51
#5  0x00000001001b7a83 in sys::begin_unwind_::_89e154cd0915671::_07pre ()
#6  0x00000001001b7b52 in sys::__extensions__::fail_with::anon::anon::expr_fn_22379 ()
#7  0x00000001001062a4 in sys::__extensions__::meth_10847::fail_with::_db4c44d01ce4116::_07pre ()
#8  0x0000000100079ca3 in comm::__extensions__::send_9140::_6efa6b5d4827a71::_00 ()
#9  0x000000010006d155 in server::anon::anon::expr_fn_8556 ()
#10 0x000000010009015d in __morestack ()
Previous frame inner to this frame (gdb could not unwind past this frame)
Current language:  auto; currently c++

[jfager]

The net code that was hitting this doesn't exist in the tree anymore.