Investigate test crushing using tokio core_threads = 4

[sdaveas]

It was observed that malicious tests fail when multiple core threads are used. Investigate the origin of this failure.

The output is:

h (t,n)=(3,4)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:D, share:4/4]"}:{round=6}:Keygen:{state="keygen [Gus-test-key] party [B] with (t,n)=(2,4)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:A, share:1/7]"}:{round=2}:Keygen:{state="keygen [Gus-test-key] party [A] with (t,n)=(6,5)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:D, share:6/9]"}:{round=2}:Keygen:{state="keygen [Gus-test-key] party [A] with (t,n)=(6,5)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:A, share:1/8]"}:{round=3}:Keygen:{state="keygen [Gus-test-key] party [C] with (t,n)=(7,8)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:A, share:1/9]"}:{round=1}: tofnd::gg20: sign failure: "Expected sign init message"
thread 'tokio-runtime-worker' panicked at 'sign failure to complete', src/tests/tofnd_party.rs:167:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError(())', src/tests/tofnd_party.rs:44:45
kv_manager stop

[sdaveas]

A related issue is that, when using multiple core threads logs are mixed.

this is a single line containing multiple logs

Apr 28 20:19:22.438  INFO Keygen:{state="keygen [Gus-test-key] party [D] with (t,n)=(3,4)"}:{round=3}:Sign:{state="sign [Gus-test-sig] party [uid:A, share:1/6]"}:{round=7}:Keygen:{state="keygen [Gus-test-key] party [B] with (t,n)=(3,4)"}:{round=1}:Sign:{state="sign [Gus-test-sig] party [uid:C, share:3/4]"}:{round=3}: tofnd::gg20::protocol: end

[sdaveas]

After a few tries I observe that there are no problems with core_threads > 4, but the problem still occurs with 2 <= core_threads <= 4.

[sdaveas]

Perhaps the problem lies at the acquisition of ports where TcpListener::bind() is called from TofndParty.rs. The following program creates 1000 threads, each one of which creates a new tcp listener.

use std::net::{TcpListener, SocketAddr};
use std::thread;

fn main() {
    for _ in 0..1000 {
        thread::spawn(|| {
            let listener = TcpListener::bind(SocketAddr::from(([0, 0, 0, 0], 0))).unwrap();
            println!("port: {}", listener.local_addr().unwrap().port());
        });
    }
}

Investigating the output of the below code, I see that it contains 63 duplicates.

It is possible that some ports are allocated, and become available again after the underlying case has finished, but some of the duplicates are suspiciously close:

port 41821 in position 214 and 215
port 39377 in position 862 and 870

Update:
Or maybe it's logical for the system to delete the listener and free the port since each thread returns immediately.

[sdaveas]

closed by #205