Re: [Grep-devel] [platform-testers] new snapshot available: grep-3.1.46-504af

[Bruno Haible]

Hi Jim, Assaf,

> > "stack-overflow" test fails on:
> >     Ubuntu 14.04/aarch64
> 
> Thanks for the speedy testing.
> Would you please tell me what this prints on that failing Ubuntu aarch64 
> system?
> 
>   i=200; printf %0${i}0000d 0|tr 0 '(' > in; src/grep -Ef in; echo $?
> 
> Wondering if their glibc is old enough ...

It is not glibc. It is an environment problem: Somehow the ulimits are
getting reset when the test script test executed.

In details: I reproduce the issue on gcc113.fsffrance.org (a Linux/aarch64
machine) in 64-bit mode.
That is, the test fails with 'grep never printed "stack overflow"'. But
when I run the commands interactively, grep prints "stack overflow" already
at the second round:

$ printf %010000d 0 | tr 0 '(' > in ; ./grep -E -f in
./grep: in:1: Unmatched ( or \(
$ printf %020000d 0 | tr 0 '(' > in ; ./grep -E -f in
grep: stack overflow

So added an 'ulimit -a > ulimit.out' command in the test, and the result is

stack size              (kbytes, -s) unlimited

which is different than what I have in my interactive environment:

stack size              (kbytes, -s) 8192

So probably 'make' or '/bin/sh' must be resetting the stack size. I was
not able to find out where this happens. But the fix is trivial: If
'ulimit -s' does not report a number, it must be reporting "unlimited"
(possibly localized), and then we can limit it.

The attached patch fixes the issue for me.

0001-tests-stack-overflow-Avoid-test-failure-on-some-Linu.patch
Description: Text Data