On Mon, Jan 23, 2023 at 04:44:21PM +0100, Stefan Sperling wrote:
> On Mon, Jan 23, 2023 at 08:25:31AM -0700, Tracey Emery wrote:
> > Here is this. I haven't had time to look it over.
> 
> Could you check whether you are hitting this error path in imsg_read()?
> 
> /usr/src/lib/libutil/imsg.c:
> [[[
> again:
> 	if (getdtablecount() + imsg_fd_overhead +
> 	    (int)((CMSG_SPACE(sizeof(int))-CMSG_SPACE(0))/sizeof(int))
> 	    >= getdtablesize()) {
> 		errno = EAGAIN;
> 		free(ifd);
> 		return (-1);
> 	}
> ]]]
> 
> You could place a printf in there and recompile + reinstall libutil for
> testing. Afterwards, remove the printf and recompile + reinstall it again.
> 
> If we are hitting this then ulimit -n 32 is indeed too tight on sparc64
> (perhaps because of struct sizes?) and we need to try 33, 34, etc. until
> it works.
> 

As discussed on IRC, we are hitting this error path on sparc64. Regress
is currently passing with a ulimit of 33. So, since there appears to be
a slight variance on sparc64, let's bump everything to a ulimit of 33
and continue testing from this point.

ok?

-- 

Tracey Emery


diff /home/tracey/src/got
commit - 711bec03cb52c156a80885f2ee8ad7fce27dd57e
path + /home/tracey/src/got
blob - 64d35a24e1ecccf1e6e9472476a2d076281f3957
file + regress/cmdline/checkout.sh
--- regress/cmdline/checkout.sh
+++ regress/cmdline/checkout.sh
@@ -901,7 +901,7 @@ test_checkout_ulimit_n() {
 	# Checkout should still work; if it does not, then either there is
 	# a bug or the fixed limit used by this test case is no longer valid
 	# and must be raised. Use a subshell to avoid changing global ulimit.
-	(ulimit -n 32; got checkout -q $testroot/repo $testroot/wt \
+	(ulimit -n 33; got checkout -q $testroot/repo $testroot/wt \
 		> $testroot/stdout)
 	ret=$?
 	if [ $ret -ne 0 ]; then