While building this port with poudriere and 13-CURRENT jail, I experienced strange build error, If I build it with 'poudriere testport' then it is built successfully. https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2019-10-10_00h38m18s/logs/openjdk12-12.0.2+10.3.log But if I build it with 'poudriere bulk' then it fails to build. https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2019-10-09_17h51m57s/logs/openjdk12-12.0.2+10.3.log With 12.0-RELEASE jail build succeeds with both 'poudriere testport' and 'poudriere bulk'. Environments are, * Host - Guest VM of VirtualBox on 64bit Windows 10 ver. 1903 - 4 CPUs, 8GB Memory, 100GB Disk - 13-CURRENT amd64 base r353107 GENERIC, WITHOUT_LIB32=yes * Poudriere 3.3.2_1 * Jail 13-CURRENT amd64 base r353107 GENERIC * Ports tree Head ports r513940
CC'ing markj@ to see if he can help diagnose, given the error: nm: 'shenandoahBarrierSetAssembler_x86.o': Socket is not connected I've experienced the same with testport vs. bulk, the former not reproducing. It looks like some kind of libcasper/socket bug, perhaps, but I can't imagine where you'd get ENOTCONN unless the casper service is getting killed.
(In reply to Kyle Evans from comment #1) I've been wondering if this could be caused by the bug fixed in r357110. In particular, prior to that revision it is possible for the unix socket GC to erroneously close in-flight descriptors in some cases. I need to think about whether that could happen with caspsicum.
(In reply to Mark Johnston from comment #2) I'm having the same issue with r359017, so it's doesn't seem to have been fixed in r357110.
(In reply to Maciej Pasternacki from comment #3) Is the issue occurring with the openjdk port as well?
(In reply to Mark Johnston from comment #4) There is no openjdk port, all have numbers. I'm seeing it in java/openjdk12 (which also prevents me from building any later openjdk, because the bootstrap JDKs are chained 11->12->13->14). I know that that r359017 is more than a month old, I'll update my build machine soon and check whether the problem persists.
build error still present in poudriere with r361307
(In reply to Dima Panov from comment #6) I'm looking at this again. Could you provide the build log from this instance?
This looks like a libcasper bug: $ pwd /home/mark/src/freebsd-ports/java/openjdk12/work/openjdk-jdk12u-jdk-12.0.2-10-4/build/bsd-x86_64-server-release/hotspot/variant-server/libjvm/objs $ limits -n 1023 nm --defined-only *.o >/dev/null nm: 'shenandoahBarrierSetAssembler_x86.o': Socket is not connected $ limits -n 1024 nm --defined-only *.o >/dev/null $ limits -n 1022 nm --defined-only *.o >/dev/null $
(In reply to Mark Johnston from comment #8) Failure log is http://build.miwi.cc/data/130amd64-dimaports/2020-05-24_21h29m36s/logs/errors/openjdk12-12.0.2+10.4.log However, thanks for the tip. Set MAX_FILES=2048 in poudriere.conf is also fixes the problem. http://build.miwi.cc//data/130amd64-dimaports/2020-05-26_09h59m12s/logs/openjdk12-12.0.2+10.4.log
Should be fixed by https://reviews.freebsd.org/D25095
A commit references this bug: Author: markj Date: Mon Jun 1 15:32:14 UTC 2020 New revision: 361694 URL: https://svnweb.freebsd.org/changeset/base/361694 Log: cap_fileargs: Fix a descriptor leak in the service process. The service handler for fileargs_open() tries to pre-open multiple files and pass descriptors for each back to the sandboxed process in a single message. This is to amortize the cost of round-trips between the two processes. The service process adds a "cache" nvlist to the reply to "open", containing file descriptors for pre-opened files. However, when adding that nvlist to the reply, it was making a copy, effectively leaking the cached descriptors. While here, fix spelling in a local variable name. PR: 241226 Reviewed by: oshogbo MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D25095 Changes: head/lib/libcasper/services/cap_fileargs/cap_fileargs.c
I forgot that cap_fileargs is not in stable/12, so no MFC is needed. Please re-open the bug if you continue to see these kinds of build errors.