search

Munksgaard / session-types

MIT License
549 stars 21 forks source link

Travis CI error #64

Open Munksgaard opened 3 years ago

Munksgaard commented 3 years ago

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

The error message is a bit disconcerting...

laumann commented 3 years ago

That looks odd.

laumann commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

It happened again! This time on nightly:

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

laumann commented 3 years ago

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 commented 3 years ago

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 https://github.com/Munksgaard/session-types/issues/64#issuecomment-690669631, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYJVPA2QXQN3D4BMMXAQTSFESZXANCNFSM4QU56MDA.

Munksgaard commented 3 years ago

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

Manishearth commented 3 years ago

No idea.

Munksgaard commented 3 years ago

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.