Travis CI error

[Munksgaard]

What went wrong here? https://travis-ci.org/github/Munksgaard/session-types/jobs/723468416

The error message is a bit disconcerting...

[laumann]

That looks odd.

[laumann]

My best bet is that it's something to do with the rustc version? I'm gonna try with rustc 1.47.0-beta.2 (84b047bf6 2020-08-28)

[Munksgaard]

It fixed itself the next day using the same version of rustc: https://travis-ci.org/github/Munksgaard/session-types/jobs/723815091

So I think it's either because of an undiscovered race-condition in our code, or a failure on Travis. I guess it could also be a race condition in the library or compiler...

[laumann]

It fixed itself the next day using the same version of rustc: https://travis-ci.org/github/Munksgaard/session-types/jobs/723815091 So I think it's either because of an undiscovered race-condition in our code, or a failure on Travis. I guess it could also be a race condition in the library or compiler...

Hmm, that's both good and bad I think :-) I couldn't reproduce it either...

[Munksgaard]

Some worrying details from the log:

(signal: 4, SIGILL: illegal instruction)

thread panicked while panicking. aborting.

Also, the test is supposed to panic, so shouldn't the panic be picked up by the test system?

[Munksgaard]

It happened again! This time on nightly:

https://travis-ci.org/github/Munksgaard/session-types/jobs/725958105

[laumann]

It happened again! This time on nightly:

That's really weird. Could it be a racy thing? Something like one thread will panic if another exits sooner than expected? IIRC this was the problem that Wen Kokke ran into.

[Munksgaard]

No, I believe hers was caused by a bug in the drop handler. Afaik, it actually segfaulted, whereas this is caught by rust, albeit weirdly so.

…

On Thu, Sep 10, 2020, at 21:33, Thomas Bracht Laumann Jespersen wrote: > It happened again! This time on nightly: That's really weird. Could it be a racy thing? Something like one thread will panic if another exits sooner than expected? IIRC this was the problem that Wen Kokke ran into. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABYJVPA2QXQN3D4BMMXAQTSFESZXANCNFSM4QU56MDA>.

[Munksgaard]

@Manishearth Would you have any idea what's going on here?

[Manishearth]

No idea.

[Munksgaard]

Aha! I think I have managed to reproduce the error locally:

extern crate session_types;

use session_types::*;

fn server(c: Chan<(), Recv<(), Eps>>) {
    let (c, ()) = c.recv();
    c.close();
}

fn drop_client(_c: Chan<(), Send<(), Eps>>) {}

#[test]
#[should_panic]
fn server_client_incomplete_panics_2() {
    let (c1, c2) = session_channel();
    drop_client(c1);
    server(c2);
}

I think we should get rid of the Drop impl. Yes, it will then be possible to cause a deadlock when using session_channel as in the example I just posted, but a SIGKILL and illegal instruction might be worse.