unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue.org>
To: 43521@debbugs.gnu.org
Subject: bug#43521: ports.test "non-revealed port is closed" breaks other tests
Date: Sat, 19 Sep 2020 14:25:45 -0500	[thread overview]
Message-ID: <87ft7d601y.fsf@trouble.defaultvalue.org> (raw)


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





             reply	other threads:[~2020-09-19 19:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-19 19:25 Rob Browning [this message]
2020-09-19 19:35 ` bug#43521: ports.test "non-revealed port is closed" breaks other tests Rob Browning
2020-09-19 20:40   ` Rob Browning
2021-01-11 15:14     ` Mathieu Othacehe
2022-03-20 21:54 ` Maxime Devos
2023-12-04 21:08 ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ft7d601y.fsf@trouble.defaultvalue.org \
    --to=rlb@defaultvalue.org \
    --cc=43521@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).