threads / bug / 38420

[BUG?] setting ulimit in test suite broken for me

Subject: [BUG?] setting ulimit in test suite broken for me

## tl;dr

3 messages between Jan 21, 2015 and Jan 22, 2015.

replies: 2people: 2as markdown or json

Stefan Beller· Jan 21, 2015, 18:59 UTC · lore
Hi,
so I wanted to create a new test for large transactions, which should look like:
	run_with_limited_open_files () {
		(ulimit -n 64 && "$@")
	}
	test_lazy_prereq ULIMIT 'run_with_limited_open_files true'
	test_expect_success ULIMIT 'large transaction creating branches does not burst open file limit' '
	(
		echo $(ulimit -n)
		for i in $(seq 65)
		do
			echo "create refs/heads/$i HEAD"
		done >large_input &&
		git update-ref --stdin <large_input &&
		git rev-parse --verify -q refs/heads/65
	)
	'

Mind the "echo $(ulimit -n)" in there as a debugging output. So if I run the test with "-d -v" to actually see the debugging output, I see ulimit -n set to 32768 instead of the desired 64.

So I assumed I made a mistake and looked at other places with a similar pattern such as in t7004-tag.sh. Inserting a debug statement (as attached, so I don't need (to trust) -d and -v as parameters for the test) in there also doesn't report the desired stack size of 128, but rather the system default of 8192. Is that just my system or does anybody else also run into such a problem?

Running ulimit -{n,s} manually in a shell (/bin/sh) as well as bash does work as expected as it correctly reports with ulimit -a as well as breaking the tests I try to write.

Thanks, Stefan

Signed-off-by: Stefan Beller <sbeller@google.com>
---
 t/t7004-tag.sh | 1 +
 1 file changed, 1 insertion(+)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 35c805a..4f09cb4 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1460,20 +1460,21 @@ test_expect_success 'invalid sort parameter in configuratoin' '
 '
 
 run_with_limited_stack () {
 	(ulimit -s 128 && "$@")
 }
 
 test_lazy_prereq ULIMIT 'run_with_limited_stack true'
 
 # we require ulimit, this excludes Windows
 test_expect_success ULIMIT '--contains works in a deep repo' '
+	echo $(ulimit -s) > ../ulimit_recorded
 	>expect &&
 	i=1 &&
 	while test $i -lt 8000
 	do
 		echo "commit refs/heads/master
 committer A U Thor <author@example.com> $((1000000000 + $i * 100)) +0200
 data <<EOF
 commit #$i
 EOF"
 		test $i = 1 && echo "from refs/heads/master^0"
-- 
2.2.1.62.g3f15098
Jeff King· Jan 21, 2015, 19:03 UTC · re: Stefan Beller · lore

Re: [BUG?] setting ulimit in test suite broken for me

On Wed, Jan 21, 2015 at 10:59:06AM -0800, Stefan Beller wrote:
Show 23 quoted lines
> so I wanted to create a new test for large transactions, which should look like:
> 
> 	run_with_limited_open_files () {
> 		(ulimit -n 64 && "$@")
> 	}
> 
> 	test_lazy_prereq ULIMIT 'run_with_limited_open_files true'
> 
> 	test_expect_success ULIMIT 'large transaction creating branches does not burst open file limit' '
> 	(
> 		echo $(ulimit -n)
> 		for i in $(seq 65)
> 		do
> 			echo "create refs/heads/$i HEAD"
> 		done >large_input &&
> 		git update-ref --stdin <large_input &&
> 		git rev-parse --verify -q refs/heads/65
> 	)
> 	'
> 
> Mind the "echo $(ulimit -n)" in there as a debugging output.
> So if I run the test with "-d -v" to actually see the debugging output,
> I see ulimit -n set to 32768 instead of the desired 64.

You define run_with_limited_open_files, which starts a subshell, drops the limit inside the subshell, and then spawns the child. But you never call it in the test. Were you expecting that tests with the ULIMIT prereq to automatically respect the limit? The prereq is just about checking whether we can set the ulimit at all.

Try:
  run_with_limited_open_files ulimit -n

in your debugging statement (and of course use run_with... for the actual git command you want to limit).

-Peff
Stefan Beller· Jan 22, 2015, 00:54 UTC · re: Jeff King · lore

Re: [BUG?] setting ulimit in test suite broken for me

On Wed, Jan 21, 2015 at 11:03 AM, Jeff King <peff@peff.net> wrote:
>
> in your debugging statement (and of course use run_with... for the
> actual git command you want to limit).
>
Thanks for that hint, its now part of the bugfix series.
Stefan

← back to recent threads