FreeBSD CI Weekly Report 2019-03-24

[Kyle Evans]

On Mon, Mar 25, 2019 at 6:24 AM Li-Wen Hsu <lwhsu at freebsd.org> wrote:
>
> (bcc -current and -stable for more audience)
>
> FreeBSD CI Weekly Report 2019-03-24
> ===================================
>
> Here is a summary of the FreeBSD Continuous Integration results for
> the period from 2019-03-18 to 2019-03-24.
>
> During this period, we have:
>
> * 2286 builds (98.3% passed, 1.7% failed) were executed on aarch64,
> amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64,
> powerpcspe, riscv64, sparc64 architectures for head, stable/12,
> stable/11 branches.
> * 498 test runs (37.3% passed, 60.7% unstable, 2% exception) were
> executed on amd64, i386, riscv64 architectures for head, stable/12,
> stable/11 branches.
> * 15 doc buils (100% passed)
>
> (The statistics from experimental jobs are omitted)
>
> If any of the issues found by CI are in your area of interest or
> expertise please investigate the PRs listed below.
>
> The latest web version of this report is available at
> https://hackmd.io/s/rybS4spvN and archive is available at
> http://hackfoldr.org/freebsd-ci-report/, any help is welcome.
>
> ## Failing Tests
>
> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/
>     * lib.libarchive.functional_test.test_fuzz_zip
>       (flakey) See https://bugs.freebsd.org/236300 for more details
>
> * https://ci.freebsd.org/job/FreeBSD-head-i386-test/
>     * sys.netmap.ctrl-api-test.main
>     * sys.opencrypto.runtests.main
>     * lib.libc.regex.exhaust_test.regcomp_too_big
>     * lib.libregex.exhaust_test.regcomp_too_big
>     * sys.kern.coredump_phnum_test.coredump_phnum
>       WIP: https://reviews.freebsd.org/D18495
>     * lib.libc.sys.sendfile_test.fd_positive_shm_v4
>     * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4
>

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.

> [... snip ...]

Thanks,

Kyle Evans