Assertion failure in mpsc/shared.rs on stable

[generalelectrix]

Hello! I have a Rust program that is failing with this assertion failure and associated traceback. There is no unsafe code involved and I'm not doing anything fancy with channels.

Rust version 1.18.0 (stable) (see verbose version info below)

Here's the error and backtrace (the unexpected large number on the left side is different each run; a few examples are 4527882240, 4458676224):

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `4540465152`, right: `0`)', src/libstd/sync/mpsc/shared.rs:253
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: <std::sync::mpsc::shared::Packet<T>>::decrement
   7: <std::sync::mpsc::shared::Packet<T>>::recv
   8: <std::sync::mpsc::Receiver<T>>::recv_max_until
   9: <std::sync::mpsc::Receiver<T>>::recv_timeout
  10: <console_server::reactor::Reactor<C>>::poll_command
  11: <console_server::reactor::Reactor<C>>::run_one_iteration
  12: <console_server::reactor::Reactor<C>>::run
  13: console_server::run
  14: core_console_test::main
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start
  17: main

rustc 1.18.0 (03fc9d6 2017-06-06)
binary: rustc
commit-hash: 03fc9d6
commit-date: 2017-06-06
host: x86_64-apple-darwin
release: 1.18.0
LLVM version: 3.9

[Mark-Simulacrum]

If you can, could you post the code that causes this failure? That way we can reproduce this problem quicker.

[generalelectrix]

I'll need to boil it down to something minimal, right now it happens in a long-running server application when accepting a new client request.

[generalelectrix]

I don't expect anyone to dive this far into my code, but here is the exit from my library into std where the assertion fails:
https://github.com/generalelectrix/wiggles/blob/master/console_server/src/reactor.rs#L334

The conditions are, vaguely:

• The main thread is blocking here waiting for a message on this channel.
• Another thread has just received a websocket request and is cloning the sender for that channel and handing it off into a newly-spawned thread. No message has been sent on this channel yet.

[generalelectrix]

Wow, that was remarkably easy to reproduce in a minimal example:

use std::sync::mpsc::channel;
use std::time::Duration;
use std::thread;

fn main() {
    let (send, recv) = channel();

    thread::spawn(move || {
        thread::sleep(Duration::from_secs(1));
        let send = send.clone();
        thread::sleep(Duration::from_secs(1));
    });

    loop {
        match recv.recv_timeout(Duration::from_millis(20)) {
            Ok(s) => {let r: String = s;}
            Err(_) => {}
        }
    }
}

I put this into a fresh cargo project and ran it with cargo run. It reliably reproduces the error:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `4485943328`, right: `0`)', src/libstd/sync/mpsc/shared.rs:253
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: <std::sync::mpsc::shared::Packet<T>>::decrement
   7: <std::sync::mpsc::shared::Packet<T>>::recv
   8: <std::sync::mpsc::Receiver<T>>::recv_max_until
   9: <std::sync::mpsc::Receiver<T>>::recv_timeout
  10: channel_bug::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main

Same system specs as before

rustc 1.18.0 (03fc9d622 2017-06-06)
binary: rustc
commit-hash: 03fc9d622e0ea26a3d37f5ab030737fcca6928b9
commit-date: 2017-06-06
host: x86_64-apple-darwin
release: 1.18.0
LLVM version: 3.9

[generalelectrix]

Reproduced the error in the playground with the above code snippet:
https://play.rust-lang.org/?gist=a6b45ca0df7570ebdf215ba7361853c9&version=stable&backtrace=0

Same error running it in the playground on nightly
rustc 1.20.0-nightly (ab5bec2 2017-06-22)

The integer32 playground reproduces it as well.

[alexcrichton]

I believe this is a duplicate of #39364 so closing in favor of that, but thanks for the report!