16:14:42 [DEBUG] (2) net::channel::stop(): END => address=tcp+tls://lilith1.dark.fi:5262 remote=485041065
16:14:42 [DEBUG] (2) net::p2p::seed(): P2P::seed() [END]
16:14:42 [DEBUG] (2) net::channel::main_receive_loop(): dnet sending recv msg, remote 485041065
thread '<unnamed>' panicked at src/net/channel.rs:314:32:
called `Option::unwrap()` on a `None` value
So the bug is caused after running p2p.seed(), where after
channel.stop() is called, main_receive_loop() keeps running. Examining
the code further we see ch.stop().await is called and the session is
destroyed but this doesn't give enough time for the channel to finish.
One solution is to modify `net/session/seedsync_session.rs` to this:
let stop_sub = ch.subscribe_stop().await;
ch.stop().await;
stop_sub.recv().await;
stop_sub.unsubscribe().await;
However a better solution is to make channel.stop() itself await until
the channel is fully closed (using the above code inside Channel::stop())
But the better solution is to ensure that StoppableTask.stop() itself
will not finish until the task it's responsible for has finished and
is no longer running. We do that by adding a stop barrier (see diff).
* Dockerfile.almalinux and fix builds, latest working b36861fa1d_2023-06-13
* Docker build can skip tests, add runtime deps
* update Fedora and Almalinux dockerfiles, worked for 95d0f47_2023-08-11 with "--build-arg DONT_EXEC_TESTS=1 --build-arg RUST_VER=nightly"
---------
Co-authored-by: parazyd <parazyd@dyne.org>
Add check for indexing into byte array
Add regression unit test using input discovered via fuzzing
Co-authored-by: y <y>
Co-authored-by: parazyd <parazyd@users.noreply.github.com>
* zkas: fix out-of-memory panic
Fix panic due to unchecked Vec::with_capacity inputs. Also change
VecDeque to use the same validation pattern even though it was not
directly affected
Add panic regression unit test based on fuzzer input that caused the crash
* Add the vec alloc try to async serial as well
---------
Co-authored-by: y <y>
Co-authored-by: parazyd <parazyd@dyne.org>
Add more documentation to fuzz/README.md, especially when it comes to
interpreting out-of-memory issues.
Co-authored-by: y <y>
Co-authored-by: parazyd <parazyd@users.noreply.github.com>
Use artifacts/ rather than corpus/ to track fuzz inputs. corpus appears
to be a temporary directory that will be modified when minimizing test
cases using commands like `cargo fuzz cmin` or `cargo fuzz tmin`. For
this reason it's not suitable for long-term storage and is likely to
make the git commit-staging process very messy.