On Sun, Sep 10, 2017 at 02:27:47PM +0200, Michael J Gruber wrote:
> This apparantly expects "ulimit -s" to fail on platforms that don't
> support it, so set the prereq accordingly. I moved the following to
> t/test-lib.sh:
>
> run_with_limited_stack () {
> (ulimit -s 128 && "$@")
> }
>
> test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'
>
> Same things as above. Two things to note:
> - Those requisites could be the same, also they are used in different ways.
> - "ulimit -s" returning success without doing anything means that, all
> along, we ran the existing tests when we didn't mean to (on Win), and
> they succeeded for the wrong reason, which we did not notice.
Right, if ulimit doesn't actually limit, then the test isn't really
accomplishing anything. But we likely have several tests in our suite
that do that. As long as they do something on _some_ platforms, they're
still useful. And as long as their failure mode is a false-pass, they
don't bother people on the other platforms.
So I think one option is to just leave it.
> So, I guess, short of testing the effect of "ulimit -s" with another
> expensive test, it's best to simply set these prerequisites based on
> "uname -s".
You can make a cheap test that uses a lot of stack. E.g., this program
runs in about 3ms on my machine, and you can reliably run "ulimit -s 128
&& ./a.out >/dev/null" to detect it segfaulting:
-- >8 --
#include <stdio.h>
/*
* Our goal is to use a lot of stack space relatively cheaply. To do that,
* allocate a big stack buffer and recurse. But we take a few precautions to
* avoid a clever compiler optimizing away our stack:
*
* - we need to use the buffer so that it can't be eliminated
*
* - we recurse after touching the buffer but before printing it,
* which makes it hard to do tail-recursion.
*/
static void foo(unsigned x)
{
size_t i;
unsigned char buf[1024];
if (!x)
return;
for (i = 0; i < sizeof(buf); i++)
buf[x] = x & 0xff;
foo(x - 1);
fwrite(buf, 1, sizeof(buf), stdout);
}
int main(void)
{
foo(128);
return 0;
}
-- 8< --
One downside is that it means git's test suite would (on a successful
run) stimulate segfaults, which are sometimes tracked and logged by the
kernel (or may even generate coredumps outside of the test suite area).
-Peff
