I am the maintainer of sysutils/javaservicewrapper and have received the following mail recently: ======================= You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: michael.osipov@siemens.com Log URL: http://ampere2.nyi.freebsd.org/data/main-arm64-default/p9fe69f91ad22_s9b2a35b3a9/logs/javaservicewrapper-3.5.49.log Build URL: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p9fe69f91ad22_s9b2a35b3a9 Log: =>> Building sysutils/javaservicewrapper build started at Tue May 17 00:39:02 UTC 2022 port directory: /usr/ports/sysutils/javaservicewrapper package name: javaservicewrapper-3.5.49 building for: FreeBSD main-arm64-default-job-03 14.0-CURRENT FreeBSD 14.0-CURRENT 1400059 arm64 maintained by: michael.osipov@siemens.com Makefile ident: Poudriere version: 3.2.8-21-g883afb07 Host OSVERSION: 1400050 Jail OSVERSION: 1400059 Job Id: 03 ... =======================<phase: build >============================ ===> Building for javaservicewrapper-3.5.49 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=6574, tid=0x000000000004c9e0 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_332-b09) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.332-b09 mixed mode bsd-aarch64 compressed oops) # Core dump written. Default location: /wrkdirs/usr/ports/sysutils/javaservicewrapper/work/wrapper_3.5.49_src/java.core # # An error report file with more information is saved as: # /wrkdirs/usr/ports/sysutils/javaservicewrapper/work/wrapper_3.5.49_src/hs_err_pid6574.log # # If you would like to submit a bug report, please visit: # https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Ports%20%26%20Packages&component=Individual%20Port(s)&short_desc=java/openjdk8%3A%20 # *** Signal 6 Stop. make: stopped in /usr/ports/sysutils/javaservicewrapper ============================ I assume that basically at the start of Ant the JVM crashes. The error seems already to be known and fixed: * https://bugs.openjdk.java.net/browse/JDK-8247766 * https://bugs.openjdk.java.net/browse/JDK-8266885 Though, the port maintainer needs to take a look whether the patch is in the BSD port and why it still crashes. I don't have access to any ARM hardware. I cannot assist here.
Created attachment 234017 [details] E-Mail from pkg-fallout
It's probably due to aslr, see bug #260187
(In reply to Mikael Urankar from comment #2) Thanks for the reference. Seems like issue is sill open.
(In reply to Mikael Urankar from comment #2) not related to aslr, sysutils/javaservicewrapper builds fine if openjdk8 is built with llvm12.
(In reply to Mikael Urankar from comment #4) Compared to LLVM from base which "FreeBSD clang version 14.0.3"?
*** Bug 264154 has been marked as a duplicate of this bug. ***
*** Bug 264165 has been marked as a duplicate of this bug. ***
The same error is also displayed when building benchmarks/scimark2: ===> Building for scimark2-java-2.0_2 cd /wrkdirs/usr/ports/benchmarks/scimark2/work/scimark2-java-2.0_2 && /usr/local/openjdk8/bin/javac -O commandline.java # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=1847, tid=0x000000000006fd66 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_332-b09) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.332-b09 mixed mode bsd-aarch64 compressed oops) # Core dump written. Default location: /wrkdirs/usr/ports/benchmarks/scimark2/work/scimark2-java-2.0_2/javac.core # # An error report file with more information is saved as: # /wrkdirs/usr/ports/benchmarks/scimark2/work/scimark2-java-2.0_2/hs_err_pid18 47.log # # If you would like to submit a bug report, please visit: # https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Ports%20%26%20Pack ages&component=Individual%20Port(s)&short_desc=java/openjdk8%3A%20 # *** Signal 6
Can we set a specific dependency on llvm12 (or LLVM < 13) until a permanent resolution can be identified, tested and landed?
Another "me too" from www/jericho-html http://ampere2.nyi.freebsd.org/data/main-arm64-default/p65d71ce9bdd9_s592e876a42/logs/jericho-html-3.2.log I can see that while upstream JDK has identified the problem, Java 8 has not yet been patched there (only in the newer JDKs). Would that be possible to add a backported patch to our JDK 8 port?
(In reply to Marcin Cieślak from comment #10) Unless I'm missing something the fix is in jdk8
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=aa1ca89826b5669e623d868e447830aad01e6f1a commit aa1ca89826b5669e623d868e447830aad01e6f1a Author: Greg Lewis <glewis@FreeBSD.org> AuthorDate: 2022-06-19 04:53:05 +0000 Commit: Greg Lewis <glewis@FreeBSD.org> CommitDate: 2022-06-19 04:55:54 +0000 java/openjdk8: Attempt to fix newer aarch64 Revert to forcing Clang 12 if Clang 13 or newer is detected. This may fix problems with the built JDK on aarch64. PR: 264065 java/openjdk8/Makefile | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #12) Can we make this change conditional on aarch64, as it seems to have never been any problem on any other architecture? Now you're basically forcing *everybody* to build yet another copy of llvm12...
(In reply to Dimitry Andric from comment #13) Please do so, this will add a lot of build time.
can we please (as already mentioned by previous comments) limit the llvm12 dependency requirement to aarch64 architecture ? Changing current Makefile to contain something like .if ${COMPILER_VERSION} >= 130 .if ${ARCH} == aarch64 # PR258954: OpenJDK <= 13 crash due to undefined behavior with clang >= 13 # See also https://bugs.openjdk.java.net/browse/JDK-8229258 LLVM_VER= 12 BUILD_DEPENDS+= clang${LLVM_VER}:devel/llvm${LLVM_VER} CC= ${LOCALBASE}/bin/clang${LLVM_VER} CXX= ${LOCALBASE}/bin/clang++${LLVM_VER} .else CONFIGURE_ARGS+= --with-extra-cflags="-Wno-unused-but-set-parameter" .endif .endif on line 207 should be enough (basically having the previous behaviour in case architecture is not aarch64, and this new patched llvm12 behaviour in case it is not aarch64)... Thank you
Gentlemen, I must express a certain disappointment in the “fix” being discussed… Take a step back and consider: we found a bug. Whether the bug is in the clang/llvm or in OpenJDK, it ought to be fixed at the source! FreeBSD project certainly has a number of C and C++ experts to come up with a proper patch suitable for submission up one of the two streams. The work-around - using a different version of LLVM - would’ve been acceptable for a few days, to accommodate some tight release deadline. But this ticket is months-old! Forcing a user to build a whole different compiler suit in order to build JDK8, is impolite too :-/
(In reply to Mikhail T. from comment #16) > Take a step back and consider: we found a bug. Whether the bug is in the > clang/llvm or in OpenJDK, it ought to be fixed at the source! FreeBSD project > certainly has a number of C and C++ experts to come up with a proper patch > suitable for submission up one of the two streams. FWIW, I have indeed tried to backport the OpenJDK upstream fix for https://bugs.openjdk.org/browse/JDK-8229258 to older JDKs. But this is *very* hairy and complicated, especially if you are not deeply invested into the JDK sources. OpenJDK upstream has apparently also drawn the same conclusion, and did not officially backport the fix to OpenJDK 8, 9, 10, 11, 12 and 13. So I think they just assume that you will compile an "old" JDK with a similarly "old" toolchain. (Note there is a pull request for OpenJDK 11 at https://github.com/openjdk/jdk11u/pull/23, but that was never merged into the official repository, as far as I can see. This was also mentioned in <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258954#c3>.) Having said all that, there may be another workaround except building with an older toolchain, which is at <https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5d554c96c1>. This is applicable to JDK 11, but I guess it might also apply to JDK 8. I believe that JDK 9 through 13 already expired, so we can ignore those. Maybe somebody has the time to check that patch?
It seems https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5d554c96c1 was already committed, and ended up in battleblow-jdk11u-jdk-11.0.15+10-1_GH0.tar.gz. So the problem originally addressed in bug 258954 is already fixed. The other issue is the "val < (1U << nbits)" error, and that appears to fixed in https://hg.openjdk.java.net/jdk/jdk/rev/40c07de877ab. I can't immediately find the corresponding backport in openjdk's awful hg interface, but https://github.com/openjdk/jdk8u/commit/638cc9a48430075bf223c25a8adb50d76d56b278 seems to be the correct one.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=591a784f324b7d8c45596d758b4c0893626bdbef commit 591a784f324b7d8c45596d758b4c0893626bdbef Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-08-06 10:54:52 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-08-06 10:55:32 +0000 java/openjdk{8,11}: Remove dependency on devel/llvm12 which is no longer necessary The workarounds committed in aa1ca89826b5 and 846ff4e95291 are no longer necessary, as both the upstream commits for PR258954 (https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5d554c96c1) and PR264065 (https://hg.openjdk.java.net/jdk/jdk/rev/40c07de877ab) are now merged into the distribution tarballs. PR: 258954, 264065 Approved by: maintainer timeout (1 month) MFH: 2022Q3 java/openjdk11/Makefile | 8 -------- java/openjdk8/Makefile | 8 -------- 2 files changed, 16 deletions(-)
The same error is still happening on aarch64. Two recent examples: http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcda7daf7a2ec_s8338690a0a/logs/tijmp-0.7_1.log http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcda7daf7a2ec_s8338690a0a/logs/errors/javaservicewrapper-3.5.49.log See build: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=pcda7daf7a2ec_s8338690a0a
The error reported at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264065#c8 is still there: http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcda7daf7a2ec_s8338690a0a/logs/scimark2-java-2.0_2.log
Re-open, the problem still exists. e.g. see http://ampere2.nyi.freebsd.org/data/main-arm64-default/p1774365e01b3_sf46bea05fe/logs/R-cran-rJava-1.0.6.log The port devel/R-cran-rJava, FreeBSD 14.0-CURRENT 1400066 arm64, fails with the following message: Java interpreter : /usr/local/bin/java Abort trap # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=77170, tid=0x00000000000661a9 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_342-b07) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.342-b07 mixed mode bsd-aarch64 compressed oops) # Core dump written. Default location: /usr/ports/devel/R-cran-rJava/java.core # # An error report file with more information is saved as: # /tmp/hs_err_pid77170.log # # If you would like to submit a bug report, please visit: # https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Ports%20%26%20Packages&component=Individual%20Port(s)&short_desc=java/openjdk8%3A%20 # *** Java interpreter doesn't work properly. *** Error code 1
Still seeing this error. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p23c196516a66_s45ad955714/logs/tijmp-0.7_1.log # Internal Error (assembler_aarch64.hpp:237), pid=46048, tid=0x00000000000f2d66 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_342-b07) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.342-b07 mixed mode bsd-aarch64 compressed oops) # Core dump written. Default location: /wrkdirs/usr/ports/devel/tijmp/work/tijmp-0.7/javac.core While we are waiting for a proper fix upstream can a committer help us, mere mortals, by committing the workaround of llvm12 from comment #15? Does it help if I upload a patch?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a705af9bfceba0fafc2612898a7afcedcb7c1865 commit a705af9bfceba0fafc2612898a7afcedcb7c1865 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-09-14 08:52:30 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-09-14 08:52:48 +0000 java/openjdk8: Restore workaround for aarch64 assertions See also <https://bugs.openjdk.org/browse/JDK-8247766>. Even though the upstream fix has been applied to this version of the JDK, some users still report the assertion "guarantee(val < (1U << nbits)) failed: Field too big for insn" occurring, when it is built with recent versions of clang. Therefore, restore the workaround that uses clang 12 to build the JDK on aarch64. PR: 264065 MFH: 2022Q3 java/openjdk8/Makefile | 10 ++++++++++ 1 file changed, 10 insertions(+)
(In reply to commit-hook from comment #24) Thanks for your commit! Does this need a portrevision bump as the port needs to be rebuild, or will it be rebuild for other reasons?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e0af091d6c934b6918032f822c4459cf5dc38f44 commit e0af091d6c934b6918032f822c4459cf5dc38f44 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-09-14 10:46:26 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-09-14 10:46:26 +0000 java/openjdk8: Bump PORTREVISION for previous change PR: 264065 MFH: 2022Q3 java/openjdk8/Makefile | 1 + 1 file changed, 1 insertion(+)
(In reply to commit-hook from comment #24) > Restore workaround for aarch64 assertions If we all agree, that this is merely a work-around, why close the ticket until the proper fix is in too?
(In reply to Mikhail T. from comment #27) Does this require an upstream fix?
(In reply to Michael Osipov from comment #28) As I noted in comment #18 and comment #19, as far as *I* can see, upstream has already backported fixes to both openjdk8 and openjdk11 for both issues: * openjdk8: - markOopDesc fix for clang >= 13: https://github.com/battleblow/jdk8u/commit/303a829ecf6172b6fe0b433e5ab2fc584702facc - aarch64 "Field too big for insn" fix: https://github.com/battleblow/jdk8u/commit/638cc9a48430075bf223c25a8adb50d76d56b278 * openjdk11: - markOopDesc fix for clang >= 13: https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5d554c96c1 - aarch64 "Field too big for insn" fix: https://github.com/battleblow/jdk11u/commit/bdaa8a38a80dacfc10a7a9bea2ea2fbfca65803f However, in comment #20, comment #21 and comment #22, several different people note that, for some reason, openjdk8 (and maybe openjdk11) is *still* crashing for them, on aarch64. Since I do not have access to (fast) aarch64 hardware, I cannot check whether they are right are not, and therefore the safest action seemed to be reversal. That said, now that I read back through the thread, could it be that after commit 591a784f324b7d8c45596d758b4c0893626bdbef (where I removed the llvm12 workaround), I also didn't bump the port revision, and therefore people were maybe running binary packages in their poudriere instances *without* the fix? I'm unsure whether poudriere figures out something changed in a dependent port; does it always need a package version bump?
(In reply to Dimitry Andric from comment #29) The tijmp failure I mentioned in comment #23 was build with this openjdk8: http://ampere2.nyi.freebsd.org/data/main-arm64-default/p23c196516a66_s45ad955714/logs/openjdk8-8.342.07.1.log That openjdk is build without bringing in llvm12. So did the fixes really go into this openjdk8? Or why else do they not work? NB: if you can't open the URLs you can try opening them via: http://www.ipv6proxy.net/
(In reply to Ronald Klop from comment #30) > The tijmp failure I mentioned in comment #23 was build with this openjdk8: > > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p23c196516a66_s45ad955714/logs/openjdk8-8.342.07.1.log > > That openjdk is build without bringing in llvm12. Yes, I can see it in the log. It is building 8.342.07.1 with the system clang 14.0.5. > So did the fixes really go into this openjdk8? Yes, I have verified that even before my changes, when 8.342.07.1 was committed, the two fixes are applied in the upstream sources. > Or why else do they not work? The "build with clang 13" fix works, since it does build with clang >= 13 (in this case, 14.0.5). The "aarch64 assertion failure" fix does not seem to work, and that is the big mystery. This fix came verbatim from openjdk8 upstream, but maybe it does not cover all situations. It is hard to tell without access to a full aarch64 debugging environment and a reproduction case. The upstream bug for this, https://bugs.openjdk.org/browse/JDK-8247766, does have a bunch of duplicates, but most of them are for backports to older JDK branches.
(In reply to Dimitry Andric from comment #31) > The "aarch64 assertion failure" fix does not seem to work, and that is the big mystery. Reopening the PR until the proper fix is implemented -- either upstream or by FreeBSD.
Isn't this fixed now with https://bugs.openjdk.org/browse/JDK-8278629?
(In reply to Michael Osipov from comment #33) Yes, as mentioned in comment 29, these fixes have been available for a long time. But some people kept reporting that it still crashed for them, so nothing has moved since. I still believe that it was fixed, but maybe I should have bumped the port revision more aggressively to force rebuilds on all sides. Then again, openjdk8 is obsolete now, so there is not much use in kicking the almost-dead horse. :)
> Then again, openjdk8 is obsolete now According to Oracle[1], "extended support" for JDK8 will be offered until 2030. And "sustaining support" will be _indefinite_. FreeBSD should be offering the version for a while... [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
(In reply to Dimitry Andric from comment #34) No, don't fall into this trap: OpenJDK != Java (Oracle). OpenJDK 8 will leave for many years through many vendors contributing to upstream.
Did a test run on modern clang/llvm for this issue. All ports mentioned in this issue as failing are now building fine with openjdk8 on aarch64 without depending on llvm12. Can somebody review this? I'm able to commit the patch myself when approved. https://reviews.freebsd.org/D46500
(In reply to Ronald Klop from comment #37) lgtm, even if I'm not part of java@. Feel free to commit under portmgr blanket approval (modernize port by using a maintained version of llvm)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=762006dfa091ef3725f813aa92db772f2e901482 commit 762006dfa091ef3725f813aa92db772f2e901482 Author: Ronald Klop <ronald@FreeBSD.org> AuthorDate: 2024-08-31 18:51:41 +0000 Commit: Ronald Klop <ronald@FreeBSD.org> CommitDate: 2024-09-03 06:52:35 +0000 java/openjdk8: (aarch64) builds fine with llvm from base ran poudriere on FreeBSD 13.3/14.0/14.1/15.0 all failing ports mentioned in the issue are building fine now: benchmarks/scimark2 devel/tijmp sysutils/javaservicewrapper www/jericho-html PR: 264065 Differential Revision: https://reviews.freebsd.org/D46500 java/openjdk8/Makefile | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-)
Verified that the named ports in this issue build fine on the pkg build cluster. Closing the issue. Thanks for the report and all the help resolving this.