Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Mar 2019 07:05:25 -0700
From:      Enji Cooper <yaneurabeya@gmail.com>
To:        Kyle Evans <kevans@freebsd.org>
Cc:        Li-Wen Hsu <lwhsu@freebsd.org>, freebsd-testing@freebsd.org
Subject:   Re: FreeBSD CI Weekly Report 2019-03-24
Message-ID:  <41F71A29-A934-408D-B57D-844EB4BC3C83@gmail.com>
In-Reply-To: <CACNAnaFC=N4K9_yqhUd_W_cDay3dH_Jss6RgCrguJw0rambMLQ@mail.gmail.com>
References:  <CAKBkRUz5zBfn=Aw4R_Z3mUgcxi55EBkOpKKSpAYyL=3r8iZkPQ@mail.gmail.com> <CACNAnaFC=N4K9_yqhUd_W_cDay3dH_Jss6RgCrguJw0rambMLQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Mar 26, 2019, at 04:51, Kyle Evans <kevans@freebsd.org> wrote:

...

> The lib.libc.regex.exhaust_test.regcomp_too_big failure should be
> fixed by r345516 pulling in an rlimit bump from upstream. They didn't
> adjust the test metadata though -- it previously reflected a memory
> requirement of 64M, which matched the rlimit imposed. I would expect
> that needs increased if we're exhausting 64M like we were on some
> systems, but I'm unsure if we should just bump that sucker to 256M or
> try to find an intermediate that's sufficient. I suspect the 256M bump
> wasn't a measurement of usage.
>=20
>> [... snip ...]

Memory serves me correctly, it used to time out with this value before, whic=
h is why pho@ and I lowered the limit to 64MB (I think we added the setrlimi=
t call).

I=E2=80=99ll have to go back and refresh my memory, since this was 3-4 years=
 ago.

-Enji=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F71A29-A934-408D-B57D-844EB4BC3C83>