bug#19005: [platform-testers] new snapshot available: grep-2.20.83-06900

[Jim Meyering]

On Sun, Nov 9, 2014 at 2:30 PM, Assaf Gordon <address@hidden> wrote:
> Hello,
>
> On 11/09/2014 04:00 PM, Jim Meyering wrote:
>>
>> Testing the first snapshot exposed several problems,
>> and most have been addressed. The sole remaining problem
>> is the failure of an "expensive" (not run by default: big-match)
>> that makes most systems run out of memory. I haven't looked at it yet.
>
>  <...>
>
>> Please let us know if you find any problems.
>
>
> Two quick tests:
>
> -1-
> On an old ubuntu 10  64-bit machine with PCRE, test
> "pcre-invalid-utf8-input" fails.
> Log attached.
> It is possible due to the test using "en_US.UTF-8" but the available locales
> are:
>
>     $ locale -a | grep en_US
>     en_US
>     en_US.utf8
>
> However, the 'get-mb-cur-max' does seem to accept "UTF-8":
>
>     $ ./tests/get-mb-cur-max en_US
>     1
>     $ ./tests/get-mb-cur-max en_US.utf8
>     6
>     $ ./tests/get-mb-cur-max en_US.UTF-8
>     6
>     $ ./tests/get-mb-cur-max en_US.FOO-8
>     (EMPTY)
>
> It is possible this old machine is mis-configured, and if so - please ignore
> this failure.
>
> Using "libpcre3" version "7.8-3build1" (from ubuntu 10 package).

Hi Assaf,
Thanks for the prompt tests and feedback.

This part of your log implicates that old ubuntu system's libpcre:

+ LC_ALL=en_US.UTF-8 timeout 3 grep -P k$ in
+ test 124 -eq 1
+ fail=1
+ echo k

That suggests that grep -P was stuck in an infinite loop when timeout
terminated the process (the exit 124).  In this case, the error is
highly desirable: it is your warning that you cannot rely on grep -P
built with that library.

> -2-
> On the same machine, which has 128 GB ram total, and 106 GB ram free:
>
>     $ free -g
>                  total       used       free     shared    buffers
> cached
>     Mem:           125         38         87          0          6
> 13
>     -/+ buffers/cache:         18        106
>     Swap:            9          3          6
>
> The "big-match" test is still skipped with "not enough main memory to run
> the test" - which sounds a bit weird.
> Log attached.
> During the execution of the tests, the "grep" process consumed up to 4.0GB
> of ram (in the "RES" column of "top").

I interrupted one run of that test when it had reached 95GB RSS.
That tests's combination of regexp and input provoke massive allocation
in regexp-internal code, albeit no leak I have seen.