Re: lib/libgcc_s fails on make all after make world succeeds

2019-05-23 Thread Ian Lepore
On Sun, 2019-05-19 at 23:54 +0200, Dimitry Andric wrote:
> On 19 May 2019, at 23:29, Julian H. Stacey  wrote:
> > 
> > Hi curr...@freebsd.org
> > On current src/ on 2 boxes, I have seen the same break for a week
> > or 2,
> > lib/libgcc_s fails on make all after make world succeeds,
> > Anyone else seen it or got ideas please ? Notes below the sample.
> > 
> > ===> lib/libgcc_s (all)
> > building shared library libgcc_s.so.1
> > cc  -nodefaultlibs -Wl,--version-
> > script=/usr/src/lib/libgcc_s/Version.map
> > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o \
> > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1
> 
> ...
> > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \
> > ld: error: can't create dynamic relocation R_X86_64_32S \
> > against symbol: __je_sz_size2index_tab in readonly segment; \
> > recompile object files with -fPIC or pass '-Wl,-z,notext' \
> > to allow text relocations in the output
> > > > > defined in
> > > > > /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o)
> 
> It looks like for some reason, it chooses to link with libc.a instead
> of
> libc.so here.  Maybe your libc.so is not getting built at all,
> because
> of your environment?
> 
> Or maybe you are hitting some build race where libc.a is done, but
> libc.so is still being built, while at the same time, libgcc_s.so.1
> is
> being linked?
> 
> There are some difficult-to-reproduce races with libgcc_s, which are
> sometimes also hit by CI (I think Li-Wen mentioned them multiple
> times
> now).  But usually I would expect this to be "solved" by simply
> re-running buildworld, as the race window is very small, and you have
> to be quite lucky (or unlucky, depending on your point of view :) to
> hit
> it.
> 
> -Dimitry
> 

There is definitely something racy going on here.  I ran into 

  /usr/bin/ld: error: unable to find library -lgcc_s

Just a couple minutes into a build with an empty /usr/obj.  I killed
it, re-emptied /usr/obj, and started it again, and it didn't repeat the
problem.

Also, I noticed that libgcc_eh and libgcc_s seem to be getting built
twice in parallel here (this is about 2 minutes into a build of 12-
stable on a 12-stable system) with -j16, so all of these libs started
building together...

--
>>> stage 4.2: building libraries
--
===> lib/libcompiler_rt (obj,all,install)
===> gnu/lib/libssp/libssp_nonshared (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/libgcc_s (obj,all,install)
===> gnu/lib/csu (obj,all,install)
===> lib/libcompiler_rt (obj,all,install)
===> lib/csu (obj,all,install)
===> lib/libc_nonshared (obj,all,install)
===> lib/libc (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
===> lib/libgcc_s (obj,all,install)
===> lib/libcxxrt (obj,all,install)

I've seen some bad things happen in the past when parallel jobs try to
build in the same directory.

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


FreeBSD CI Weekly Report 2019-05-19

2019-05-23 Thread Li-Wen Hsu
(bcc -current and -stable for more audience)

FreeBSD CI Weekly Report 2019-05-19
===

Here is a summary of the FreeBSD Continuous Integration results for
the period from 2019-05-13 to 2019-05-19.

During this period, we have:

* 1845 builds (97% passed, 3% failed) were executed on aarch64, amd64,
armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe,
riscv64, sparc64 architectures for head, stable/12, stable/11
branches.
* test runs (58.7% passed, 19.6% unstable, 21.7% exception) were
executed on amd64, i386, riscv64 architectures for head, stable/12,
stable/11 branches.
* 20 doc builds (95% passed)

Note: there was a updating of ci.freebsd.org system and resulted some
(less than 10) failures.

(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/SJIjkSeaE 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/
* 
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/11251/testReport/junit/lib.libarchive/functional_test/test_read_format_zip_utf8_paths/
  Fixed in https://svnweb.freebsd.org/changeset/base/347999

* https://ci.freebsd.org/job/FreeBSD-head-i386-test/
i386 test is current suffering from loading ipsec(4) kernel
module, which is needed after
https://svnweb.freebsd.org/changeset/base/347410 ,  causes kernel
panic.
For more information, see:
* https://bugs.freebsd.org/238012
* https://bugs.freebsd.org/230857
* https://reviews.freebsd.org/D17512

* https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/
* sys.netpfil.pf.forward.v6
* sys.netpfil.pf.forward.v4
* sys.netpfil.pf.set_tos.v4
* lib.libc.regex.exhaust_test.regcomp_too_big
* lib.libregex.exhaust_test.regcomp_too_big

* https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)

## Failing and Flaky Tests (from experimental jobs)

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
There are ~60 failing cases, including flakey ones, see
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
for more details

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d
  https://bugs.freebsd.org/237641

## Disabled Tests

* lib.libc.sys.mmap_test.mmap_truncate_signal
  https://bugs.freebsd.org/211924
* sys.fs.tmpfs.mount_test.large
  https://bugs.freebsd.org/212862
* sys.fs.tmpfs.link_test.kqueue
  https://bugs.freebsd.org/213662
* sys.kqueue.libkqueue.kqueue_test.main
  https://bugs.freebsd.org/233586
* usr.bin.procstat.procstat_test.command_line_arguments
  https://bugs.freebsd.org/233587
* usr.bin.procstat.procstat_test.environment
  https://bugs.freebsd.org/233588

## Open Issues

* https://bugs.freebsd.org/237077 possible race in build:
/usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected
relocatable expression
* https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be
converted to Python3
* https://bugs.freebsd.org/237641 Flakey test case:
common.misc.t_dtrace_contrib.tst_dynopt_d
* https://bugs.freebsd.org/237652
tests.hotspare.hotspare_test.hotspare_snapshot_001_pos timeout since
somewhere in (r346814, r 346845]
* https://bugs.freebsd.org/237655 Non-deterministic panic when running
pf tests in interface ioctl code (NULL passed to strncmp)
* https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not
empty (18 items). Lost 1 pages of memory." seen when running
sys/netipsec tests
* https://bugs.freebsd.org/237657
sys.kern.pdeathsig.signal_delivered_ptrace timing out periodically on
i386

### Cause build fails

* [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h:
error: machine/endian.h: No such file or
directory](https://bugs.freebsd.org/233735)
* [233769: Possible build race: ld: error: unable to find library
-lgcc_s](https://bugs.freebsd.org/233769)

### Others
[Tickets related to testing@](https://preview.tinyurl.com/y9maauwg)

## Other news
* https://issues.tmatesoft.com/issue/SVNKIT-740
  The patch is asked to be updated and help wanted.

* https://bugs.freebsd.org/235356
  Help on how to reproduce and analyze is wanted.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"