Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assertion failed: self.steals >= 0 #12295

Closed
jedisct1 opened this issue Feb 15, 2014 · 2 comments · Fixed by #12302
Closed

assertion failed: self.steals >= 0 #12295

jedisct1 opened this issue Feb 15, 2014 · 2 comments · Fixed by #12302

Comments

@jedisct1
Copy link
Contributor

After a few seconds, the following code dies with an assertion (tested on OSX, rust -master a7aa4c4)

task '<unnamed>' failed at 'assertion failed: self.steals >= 0', /private/tmp/rust-3eWl/src/libstd/comm/stream.rs:215
task '<main>' failed at 'sending on a closed channel', /private/tmp/rust-3eWl/src/libstd/comm/mod.rs:368

use std::comm::{Chan, Port};
fn main() {
    let (port, chan): (Port<~str>, Chan<~str>) = Chan::new();
    spawn(proc() { loop  { port.recv(); } });
    loop  { chan.send(~"test"); }
}
@sfackler
Copy link
Member

I initially thought this was just #12041, but it still hits that assert when modified to

use std::comm::Chan;

fn main() {
    let (port, chan) = Chan::new();
    spawn(proc() {
        let port = port;
        loop {
            port.recv();
        }
    });
    loop {
        chan.send(~"test");
    }
}

cc @alexcrichton

@itdaniher
Copy link
Contributor

I can reproduce this using the code above on 94d453e / x86_64-unknown-linux-gnu. Got this same message after a seemingly benign but more complicated program ran for an few minutes.

bors added a commit that referenced this issue Feb 16, 2014
The previous code erroneously assumed that 'steals > cnt' was always true, but
that was a false assumption. The code was altered to decrement steals to a
minimum of 0 instead of taking all of cnt into account.

I didn't include the exact test from #12295 because it could run for quite
awhile, and instead set the threshold for MAX_STEALS to much lower during
testing. I found that this triggered the old bug quite frequently when running
without this fix.

Closes #12295
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants