On Sat, Jul 09, 2022 at 02:23:36PM +0200, Michael J Gruber wrote:
> > +run_with_limited_processses () {
> > + # bash and ksh use "ulimit -u", dash uses "ulimit -p"
> > + if test -n "$BASH_VERSION"
> > + then
> > + ulimit_max_process="-u"
> > + elif test -n "$KSH_VERSION"
> > + then
> > + ulimit_max_process="-u"
> > + fi
> > + (ulimit ${ulimit_max_process-"-p"} 512 && "$@")
> > +}
>
> This new test fails for me unless I increase max_processes. 1024 works.
>
> I haven't bisected the number of prcesses ... This is higly system
> dependent. I even run a slim environment (i3wm) but having chrome or
> such running probably makes quite a difference.
>
> 512 is probably OK in CI in an isolated environment but is too low on a
> typical "What you mean I'm not working? I'm waiting for the test run!"
> developper workstation.
>
> Conversely, which number would be too high to catch what the test is
> supposed to catch? Does it incur a big performance penalty to go as high
> as possible?
This bit me, too. It works if I run it standalone:
$ ./t5330-no-lazy-fetch-with-commit-graph.sh
ok 1 - setup: prepare a repository with a commit
ok 2 - setup: prepare a repository with commit-graph contains the commit
ok 3 - setup: change the alternates to what without the commit
ok 4 - fetch any commit from promisor with the usage of the commit graph
# passed all 4 test(s)
but it fails when I run the whole test suite with "prove -j32". Or even
easier, just run it under "--stress":
$ ./t5330-no-lazy-fetch-with-commit-graph.sh --stress
[...]
+ run_with_limited_processses env GIT_TRACE=/home/peff/compile/git/t/trash directory.t5330-no-lazy-fetch-with-commit-graph.stress-30/trace.txt git -C with-commit-graph fetch origin ba19607defe740988a69e98bced331083e02bdd6
error: last command exited with $?=128
not ok 4 - fetch any commit from promisor with the usage of the commit graph
$ cat trash*.stress-failed/err
[...]
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack
-Peff
