Overflow in mpsc::Sender::clone leads to illegal instruction

[apasel422]

The following crashes with an illegal instruction when compiled in release mode with 1.13.0-nightly (499484f56 2016-08-18) on i686-unknown-linux-gnu:

fn main() {
    let (tx, _) = std::sync::mpsc::channel::<()>();

    for _ in 0..std::usize::MAX {
        std::mem::forget(tx.clone());
    }
}

It's presumably the result of the unchecked addition in std::sync::mpsc::shared::Packet::clone_chan. Another unchecked addition is performed in std::sync::mpsc::sync::Packet::clone_chan, and other uses of fetch_add in the mpsc module should probably be audited as well.

[arielb1]

The well-known "optimized leak attack".

[brson]

Fix the same way as with Rc/Arc.

[alexcrichton]

Discussed today at @rust-lang/libs triage and the conclusion was that this'd be great to fix but isn't P-high priority b/c it's somewhat manufactured.

As @brson said the fix will probably to just do the same thing as Arc.

[KiChjang]

I'm looking into this, should I add a test for it? Because using the example provided in the issue description causes rustc to run for a loooooooooooooooooong time, and this would hurt PR turnover rates if I include the test.

[KiChjang]

Also, why is std::sync::mpsc::shared::Packet's channels field an AtomicIsize? Shouldn't it be AtomicUsize instead?

[alexcrichton]

@KiChjang yeah it's ok to omit a test in this case and also yeah I think it's fine to change to AtomicUsize as well. Thanks!