Various test failures on macOS for the channel crate

[Thomasdezeeuw]

The following tests fail on my macOS machine.

use_while_exiting
channel_tests::oneshot_single_thread_recv_chan_close
channel_tests::oneshot_multi_task_recv_then_close
channel_tests::oneshot_multi_thread_send_close_stress
channel_tests::oneshot_multi_thread_recv_close_stress
sync_channel_tests::oneshot_single_thread_recv_chan_close
sync_channel_tests::oneshot_multi_task_recv_then_close
sync_channel_tests::oneshot_multi_thread_send_close_stress
sync_channel_tests::oneshot_multi_thread_recv_close_stress

I've added some stacktraces, I'll look into a bit further myself.

use_while_exiting

thread '<unnamed>' panicked at 'use of std::thread::current() is not possible after the thread's local data has been destroyed', src/libcore/option.rs:1038:5
stack backtrace:
   0:        0x103be2c33 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6b67c23e58603609
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:        0x103bdeee2 - std::sys_common::backtrace::_print::hd7c2b572e0c4e656
                               at src/libstd/sys_common/backtrace.rs:70
   2:        0x103be1ae6 - std::panicking::default_hook::{{closure}}::hbfd2b812b74e7516
                               at src/libstd/sys_common/backtrace.rs:58
                               at src/libstd/panicking.rs:200
   3:        0x103be17f1 - std::panicking::default_hook::h2e0df5c26761382f
                               at src/libstd/panicking.rs:215
   4:        0x103be226e - <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get::h68f156da32bb6727
                               at src/libstd/panicking.rs:478
   5:        0x103be1d8c - std::panicking::continue_panic_fmt::he9962abdc5d06fe1
                               at src/libstd/panicking.rs:385
   6:        0x103be1c78 - std::panicking::try::do_call::h62d8346540aa00a7
                               at src/libstd/panicking.rs:312
   7:        0x103bf3b51 - core::char::methods::<impl char>::escape_debug::hb08634abedefbc98
                               at src/libcore/panicking.rs:85
   8:        0x103bf3bbd - core::char::methods::<impl char>::escape_debug::hb08634abedefbc98
                               at src/libcore/option.rs:1038
   9:        0x103bd7403 - std::thread::local::fast::destroy_value::hf33fd5c734a85c9f
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/option.rs:312
                               at src/libstd/thread/mod.rs:634
                               at src/libstd/thread/mod.rs:979
  10:        0x103b7576c - crossbeam_channel::context::Context::wait_until::h5eb53df73e5de213
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/context.rs:164
  11:        0x103b8a2b1 - <crossbeam_channel::flavors::list::Channel<T>>::recv::{{closure}}::h098a36b3adabc276
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/flavors/list.rs:460
  12:        0x103b71199 - crossbeam_channel::context::Context::with::{{closure}}::hca3ee535e7811b46
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/context.rs:49
  13:        0x103b70eb0 - crossbeam_channel::context::Context::with::{{closure}}::h4813d2c21ba88c9e
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/context.rs:57
  14:        0x103b85532 - <std::thread::local::LocalKey<T>>::try_with::hd10b881afdac9910
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/thread/local.rs:296
  15:        0x103b70876 - crossbeam_channel::context::Context::with::hf543e68aa118343d
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/context.rs:52
  16:        0x103b8a172 - <crossbeam_channel::flavors::list::Channel<T>>::recv::hec51c42ae74796f3
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/flavors/list.rs:450
  17:        0x103b8f1d6 - <crossbeam_channel::channel::Receiver<T>>::recv_timeout::h04aefd3333927d07
                               at /Users/thomas/src/third_party/crossbeam/crossbeam-channel/src/channel.rs:765
  18:        0x103b8f934 - <thread_locals::use_while_exiting::Foo as core::ops::drop::Drop>::drop::h53a589e6e5410653
                               at crossbeam-channel/tests/thread_locals.rs:26
  19:        0x103b71ad4 - core::ptr::real_drop_in_place::h18254c392ba449e7
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/ptr.rs:193
  20:        0x103b71c74 - core::ptr::real_drop_in_place::h28bad489b5999d2f
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/ptr.rs:193
  21:        0x103b6e65e - std::thread::local::fast::destroy_value::hdaded25d6ae9ce76
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/ptr.rs:183
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/thread/local.rs:404
  22:        0x103be308c - std::sys::unix::fast_thread_local::register_dtor::run_dtors::h778eadaf6a6c34f5
                               at src/libstd/sys/unix/fast_thread_local.rs:80
  23:     0x7fff6188fd58 - tlv_finalize
  24:     0x7fff61ba7162 - _pthread_tsd_cleanup
  25:     0x7fff61ba6ee8 - _pthread_exit
  26:     0x7fff61ba566b - _pthread_body
  27:     0x7fff61ba550c - _pthread_start
fatal runtime error: failed to initiate panic, error 5
error: process didn't exit successfully: `/Users/thomas/src/third_party/crossbeam/target/debug/deps/thread_locals-e2a7497a066b1ef2 use_while_exiting` (signal: 4, SIGILL: illegal instruction)

channel_tests::oneshot_single_thread_recv_chan_close

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:997:5
stack backtrace:
   0:        0x100a4a633 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6b67c23e58603609
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:        0x100a46962 - std::sys_common::backtrace::_print::hd7c2b572e0c4e656
                               at src/libstd/sys_common/backtrace.rs:70
   2:        0x100a49556 - std::panicking::default_hook::{{closure}}::hbfd2b812b74e7516
                               at src/libstd/sys_common/backtrace.rs:58
                               at src/libstd/panicking.rs:200
   3:        0x100a49261 - std::panicking::default_hook::h2e0df5c26761382f
                               at src/libstd/panicking.rs:215
   4:        0x100a49cde - <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get::h68f156da32bb6727
                               at src/libstd/panicking.rs:478
   5:        0x100a497fc - std::panicking::continue_panic_fmt::he9962abdc5d06fe1
                               at src/libstd/panicking.rs:385
   6:        0x100a496e8 - std::panicking::try::do_call::h62d8346540aa00a7
                               at src/libstd/panicking.rs:312
   7:        0x100a5b551 - core::char::methods::<impl char>::escape_debug::hb08634abedefbc98
                               at src/libcore/panicking.rs:85
   8:        0x100944282 - core::result::unwrap_failed::h2a084cf6acc8df30
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/macros.rs:16
   9:        0x10093c704 - <core::result::Result<T, E>>::unwrap::ha3d5b57d381412be
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libcore/result.rs:798
  10:        0x100948407 - mpsc::channel_tests::oneshot_single_thread_recv_chan_close::{{closure}}::h8de4849b4d02e7e7
                               at crossbeam-channel/tests/mpsc.rs:429
  11:        0x10093845c - std::sys_common::backtrace::__rust_begin_short_backtrace::h2983c6c44b570738
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/sys_common/backtrace.rs:135
  12:        0x100978ebc - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::h664169b49120d917
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/thread/mod.rs:469
  13:        0x10099141c - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h31b899f3c5d0d622
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/panic.rs:309
  14:        0x1009a0219 - std::panicking::try::do_call::h5e3738726440f6f8
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/panicking.rs:297
  15:        0x100a4c60e - panic_unwind::dwarf::eh::read_encoded_pointer::h828e027e1d0844b3
                               at src/libpanic_unwind/lib.rs:92
  16:        0x10099d632 - std::panicking::try::h95c1148d64b4f91e
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/panicking.rs:276
  17:        0x100992d3c - std::panic::catch_unwind::h8dc6ec0eb3a0dd25
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/panic.rs:388
  18:        0x10096e655 - std::thread::Builder::spawn_unchecked::{{closure}}::h36f09b35e8b3c47f
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/libstd/thread/mod.rs:468
  19:        0x10097c55e - <F as alloc::boxed::FnBox<A>>::call_box::h35d302b194e96ca3
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/liballoc/boxed.rs:734
  20:        0x100a4c00b - std::sys::unix::thread::Thread::new::thread_start::h11f2cd3db8116a3d
                               at /rustc/852701ad6df90f4e4cdb11d487373f026f38e5b3/src/liballoc/boxed.rs:744
                               at src/libstd/sys_common/thread.rs:14
                               at src/libstd/sys/unix/thread.rs:81
  21:     0x7fff61ba5660 - _pthread_body
  22:     0x7fff61ba550c - _pthread_start

I've also noticed that in a lot of tests threads are spawned but never joined. Because of this the test runner think the tests passed, but in reality a lot of threads actually panicked.

Also there seems to be no CI for macOS, but Travis supports it (although it is quite slow).

[Thomasdezeeuw]

After #322 and #323 use_while_exiting is the only test that fails, see backtrace in the my original post. This is the only test I don't think I can fix.

[ghost]

Interesting. I believe use_while_exiting fails because TLS destruction time differs on Linux and macOS, so adding a cfg(...) to run this test on Linux only would be fine by me.

[Thomasdezeeuw]

@stjepang Does the channel ever depend on this behaviour?

[ghost]

It doesn't, but there was an issue in Servo where using channels while a thread is panicking would result in accessing a TLS variable declared in crossbeam-epoch that is already destroyed. The core problem is that TLS variables are destroyed at some point after the panic occurs and the thread dies, and when exactly is very platform dependent.

That test was added to make sure we're using FOO.try_with() rather than FOO.with() where appropriate. It's okay if we just skip it in on macOS.

[Thomasdezeeuw]

I think after #325 and #326 are merged this can be closed.

[ghost]

Can we close this issue?

[Thomasdezeeuw]

I would have like to have CI setup for macOS, but Travis is too slow. So I don't think there is anything else to do here.

[ghost]

If you know an alternative CI that might be more stable on macOS than Travis, we can try it out.

[Thomasdezeeuw]

There is https://cirrus-ci.org/, which for example mio uses it, but I haven't used it before. @asomers May I ask about your experience with Cirrus?

[asomers]

I mainly use Cirrus because of its FreeBSD support. The FreeBSD VMs start quickly, much quicker than Travis's OSX images. They're usually even faster than Travis's Linux containers. There have been a few bugs, especially because I was the first Cirrus FreeBSD user, but Cirrus has fixed them all very quickly. They're quite responsive when you open a Github issue. Cirrus can also build in Linux containers, which seem to work fine. And according to the docs it can build OSX images too, but I haven't tried those.

Configuring an image doesn't have quite as many bells and whistles as Travis, but it's got all of the stuff you really need. And of course you can always manually add packages. Cirrus even allows you to create a custom VM image, though that's not free. Cheap, but not free.

All-in-all, I've been happy with Cirrus.

[Thomasdezeeuw]

@asomers thanks for sharing your experience.

@stjepang I've being trying out the macOS instances on Cirrus but they don't seem faster than the machines from Travis.

[ghost]

That's unfortunate but thanks for digging into this, @Thomasdezeeuw!