On Sun, Nov 9, 2014 at 2:30 PM, Assaf Gordon <[email protected]> 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.
