Bug 241226 - java/openjdk12: Strange build error with poudriere and 13-CURRENT jail
Summary: java/openjdk12: Strange build error with poudriere and 13-CURRENT jail
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Mark Johnston
Depends on:
Reported: 2019-10-13 14:48 UTC by Yasuhiro Kimura
Modified: 2020-06-04 15:46 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (java)


Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro Kimura 2019-10-13 14:48:39 UTC
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.


But if I build it with 'poudriere bulk' then it fails to build.


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
* Jail
  13-CURRENT amd64 base r353107 GENERIC
* Ports tree
  Head ports r513940
Comment 1 Kyle Evans freebsd_committer 2020-02-02 19:57:19 UTC
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.
Comment 2 Mark Johnston freebsd_committer 2020-02-02 20:11:04 UTC
(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.
Comment 3 Maciej Pasternacki 2020-04-21 06:43:46 UTC
(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.
Comment 4 Mark Johnston freebsd_committer 2020-04-21 14:18:20 UTC
(In reply to Maciej Pasternacki from comment #3)
Is the issue occurring with the openjdk port as well?
Comment 5 Maciej Pasternacki 2020-04-25 09:59:49 UTC
(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.
Comment 6 Dima Panov freebsd_committer 2020-05-23 17:48:12 UTC
build error still present in poudriere with r361307
Comment 7 Mark Johnston freebsd_committer 2020-05-25 16:09:42 UTC
(In reply to Dima Panov from comment #6)
I'm looking at this again.  Could you provide the build log from this instance?
Comment 8 Mark Johnston freebsd_committer 2020-05-25 16:42:23 UTC
This looks like a libcasper bug:

$ pwd
$ 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
Comment 9 Dima Panov freebsd_committer 2020-05-26 08:10:02 UTC
(In reply to Mark Johnston from comment #8)
Failure log is 

However, thanks for the tip.
Set MAX_FILES=2048 in poudriere.conf is also fixes the problem.

Comment 10 Mark Johnston freebsd_committer 2020-06-01 14:47:27 UTC
Should be fixed by https://reviews.freebsd.org/D25095
Comment 11 commit-hook freebsd_committer 2020-06-01 15:33:00 UTC
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

  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

  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

Comment 12 Mark Johnston freebsd_committer 2020-06-04 15:46:01 UTC
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.