Subject: ports.test "non-revealed port is closed" breaks other tests

From: Rob Browning <[email-masked]>
Date: Sat, 19 Sep 2020 14:25:45 -0500

I think the "non-revealed port is closed" test can break other tests,
depending on the gc's behavior.  At the moment this is easy to reproduce
for some reason (presumably differing gc behavior) on the Debian s390x
machines.

I believe the problem is that if the gc doesn't collect the port when
the test calls (gc), then the test (which recognizes that possibility)
calls close-fdes on the underlying fd.  However, the port still exists,
and it may be garbage collected later, during a test that's using the
same fd, which may break that test.

I did add some low-level fprintf diagnostics which confirmed that exact
behavior.  i.e. one of the subsequent tests would call (gc), and I could
see that the old port object (identified by the %p pointer) from the
earlier "non-revealed port is closed" test, closed the fd which broke
the the current test when it attempted a seek on the fd that should
still be open.

For now, I've just commented out the test in the Debian packages, and
unless some other arrangements can be made, suspect we might want to do
the same thing in Guile itself.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4