unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#43521: ports.test "non-revealed port is closed" breaks other tests
@ 2020-09-19 19:25 Rob Browning
  2020-09-19 19:35 ` Rob Browning
  0 siblings, 1 reply; 4+ messages in thread
From: Rob Browning @ 2020-09-19 19:25 UTC (permalink / raw)
  To: 43521


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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#43521: ports.test "non-revealed port is closed" breaks other tests
  2020-09-19 19:25 bug#43521: ports.test "non-revealed port is closed" breaks other tests Rob Browning
@ 2020-09-19 19:35 ` Rob Browning
  2020-09-19 20:40   ` Rob Browning
  0 siblings, 1 reply; 4+ messages in thread
From: Rob Browning @ 2020-09-19 19:35 UTC (permalink / raw)
  To: 43521

Rob Browning <rlb@defaultvalue.org> writes:

> 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.

...and I'd have to think about it more carefully, but if dropping
the close-fdes call would completely prevent any subsequent test from
re-using the fd unsafely before the lingering port is collected, then
perhaps that's one potential fix.

-- 
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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#43521: ports.test "non-revealed port is closed" breaks other tests
  2020-09-19 19:35 ` Rob Browning
@ 2020-09-19 20:40   ` Rob Browning
  2021-01-11 15:14     ` Mathieu Othacehe
  0 siblings, 1 reply; 4+ messages in thread
From: Rob Browning @ 2020-09-19 20:40 UTC (permalink / raw)
  To: 43521

Rob Browning <rlb@defaultvalue.org> writes:

> ...and I'd have to think about it more carefully, but if dropping
> the close-fdes call would completely prevent any subsequent test from
> re-using the fd unsafely before the lingering port is collected, then
> perhaps that's one potential fix.

I ended up doing that for now:

  https://salsa.debian.org/rlb/deb-guile/-/commit/9fae58b134d8951e15b39b8e1751160a245228a6

-- 
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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#43521: ports.test "non-revealed port is closed" breaks other tests
  2020-09-19 20:40   ` Rob Browning
@ 2021-01-11 15:14     ` Mathieu Othacehe
  0 siblings, 0 replies; 4+ messages in thread
From: Mathieu Othacehe @ 2021-01-11 15:14 UTC (permalink / raw)
  To: Rob Browning; +Cc: 43521


Hello Rob,

> I ended up doing that for now:
>
>   https://salsa.debian.org/rlb/deb-guile/-/commit/9fae58b134d8951e15b39b8e1751160a245228a6

Nice catch! I had the exact same issue, reported here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45788.

Except for a small typo: s/subseuquent/subsequent, your fix looks good
to me, and could by applied mainline I think.

Thanks,

Mathieu





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-11 15:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-19 19:25 bug#43521: ports.test "non-revealed port is closed" breaks other tests Rob Browning
2020-09-19 19:35 ` Rob Browning
2020-09-19 20:40   ` Rob Browning
2021-01-11 15:14     ` Mathieu Othacehe

unofficial mirror of bug-guile@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-bugs/0 guile-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-bugs guile-bugs/ https://yhetil.org/guile-bugs \
		bug-guile@gnu.org
	public-inbox-index guile-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.bugs
	nntp://news.gmane.io/gmane.lisp.guile.bugs


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git