unix socket features: rust ipc-channel tests failing

[vvuk]

The Rust/Servo projects use a fairly core library called ipc-channel that implements an IPC version of Rust built-inchannels. It has a pretty extensive test suite which exercises many aspects of sockets on Linux. A number of these tests fail currently using LXSS from Creators' Update (15063).

• Actual results (with terminal output if applicable)

• Your Windows build number

• Steps / All commands required to reproduce the error from a brand new installation

# Install rust toolchain (installs to user home dir)
curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain nightly
# Add to PATH
. ~/.cargo/env
# Make rust stdlib src available for debugging
rustup component add rust-src

# get ipc-channel (from my repo, with a branch with a simple test)
git clone -b lx-tests https://github.com/vvuk/ipc-channel
cd ipc-channel

# run the failing example (extracted out test)
cargo run --example cs

# run all tests
export RUST_TEST_THREADS=1  # run tests single-threaded
export RUST_BACKTRACE=1 # show backtrace on failure
cargo test

Lots of failures show up. For debugging, a single test can be run by giving its name, e.g. cargo test platform::test::concurrent_senders.

An example of a failure is the concurrent_senders test -- this creates one channel, then writes to it from multiple threads N times, and receives N times back on the main thread. I'm using that example here (I've pulled out the test function into its own standalone .rs file to remove the testing wrapper -- if that's useful to do, make ipc-channel/examples/foo.rs, copy code into fn main() { } in there, and run with cargo run --example foo. Feel free to poke me here or via twitter at @vvuk for more live help :)

For concurrent-senders (in cs.rs), the issue manifests as a read() that returns 0 when a) the read is blocking to begin with; b) we know there is more data to read. If, in examples/cs.rs, the num_senders is increased to, say, 5, then the test hangs in recv(). It feels like there's some kind of internal kernel-ish buffer that's being blown silently or similar.

[therealkenc]

I mentioned back in August #897 (message) the dbus test suite. It still fails in 16170, hanging in an echo test. I would not be surprised if your rusty problem with AF_UNIX isn't similar or identical.

Repro is:

sudo apt-get install libglib2.0-dev python-dbus
wget https://dbus.freedesktop.org/releases/dbus/dbus-1.11.12.tar.gz
tar xf dbus-1.11.12.tar.gz
cd dbus-1.11.12
./configure --enable-tests
make -j8
make check

I have also seen some evidence (but can't prove) that the problem with VSCode (Electron) is with the IPC messages between Node and Blink not making it. That mechanism is AF_NETLINK though.

[sunilmut]

@vvuk - Thanks for running the tests on WSL and reporting the issue. I agree that there are some issues here that still needs to be fixed. I will mark the ticket with the bug tag and we will try to get these issues addressed.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!