Re: misc/59255: tests/lib/librumpclient/t_exec: intermittent failures

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR misc/59255; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: misc/59255: tests/lib/librumpclient/t_exec: intermittent failures
Date: Mon, 07 Apr 2025 02:00:06 +0700

     Date:        Sun,  6 Apr 2025 14:20:01 +0000 (UTC)
     From:        campbell+netbsd%mumble.net@localhost
     Message-ID:  <20250406142001.10B3B1A923E%mollari.NetBSD.org@localhost>
 
 
   | Various test cases in tests/lib/librumpclient/t_exec have
   | been intermittently failing for a while:
 
 Probably forever.   I took a look at this one in particular a
 while ago, there looks to be a fairly obvious race condition in
 the test - it vforks, then the child and parent each set argv[0]
 and re-exec the test file again - the test case looks to see that
 both processes have a shared socket open - or something like that.
 
 But that test happens when the parent exits, simply assuming that by
 that time the child will have had time to establish its setup (since,
 being vfork(), it has to exec() or exit() before the parent gets
 control back from the vfork()), and often, that works, but not always.
 When it doesn't, when the test code (the script) looks to see the state
 of the sockets it isn't what it is expecting.
 
 I would have fixed it at the time (a few months ago now), but I couldn't
 determine exactly what the test was supposed to be testing, and different
 ways to overcome the problem might break whatever that was supposed to
 be (rendering the test even more useless than it currently is).
 
 If I were to do anything, I'd probably just delete the whole test as
 being basically useless.
 
 I didn't examine the other test cases (some of which also intermittently
 fail) but I'd be not at all surprised to see much of the same from them
 (except perhaps the very basic one which doesn't do almost anything, and
 probably never fails).
 
 kre