Bug 260187
| Summary: | java/bootstrap-openjdk17: broken on aarch64 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mikael Urankar <mikael> | ||||||||
| Component: | Individual Port(s) | Assignee: | freebsd-java (Nobody) <java> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Many People | CC: | bz, fluffy, glewis, java, jfc, mikael, ronald-lists, ronald | ||||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(java) |
||||||||
| Version: | Latest | ||||||||||
| Hardware: | arm64 | ||||||||||
| OS: | Any | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Mikael Urankar
2021-12-03 11:55:27 UTC
Hmmm, I'm not sure what might be going wrong, but I can add details about the binary itself. It was built on an AWS aarch64 instance. I installed 12.2 and built the current version of the openjdk17 port. I then deleted things that weren't needed for bootstrap, like src.zip, the manual pages, the examples, etc. What version are you trying this on and how much memory does the machine have? (In reply to Greg Lewis from comment #1) It's on a recent 14-current, the board has 64gb of RAM. I tried this on both FreeBSD 12.3/arm64 and FreeBSD 13.0/arm64 and it worked on both of them. The JDK sometimes encounters problems on -CURRENT. These often end up being bugs in -CURRENT if they can't be reproduced on released versions. In this case I would suggest transferring this to the Base System category unless FreeBSD 14 is planning to deliberately break compatibility with earlier releases. Cannot reproduce with a recent 14-current, closing. (In reply to Mikael Urankar from comment #4) It happened again, setting kern.elf64.aslr.pie_enable=0 fixed it I just hit this on my honeycomb machine trying to build openjdk17 on a CURRENT from two days ago or so... ... checking bash version... 5.1.16 checking if bash supports pipefail... yes checking if bash supports errexit (-e)... yes checking pkg-config is at least version 0.9.0... yes checking for default LOG value... checking if packaged modules are kept... enabled, default checking for version string... 17.0.3+7-1 configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /usr/local/bootstrap-openjdk17 is not a working JDK; ignoring configure: Output from java -version was: Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1 ===> Script "configure" failed unexpectedly. Please report the problem to java@FreeBSD.org [maintainer] and attach the "/var/tmp/work-20220515/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.3-7-1/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[2]: stopped in /usr/ports/java/openjdk17 *** Error code 1 And I can confirm that setting the sysctl fixed it here too: # /usr/local/bootstrap-openjdk17/bin/jar --help Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes # sysctl kern.elf64.aslr.pie_enable=0 kern.elf64.aslr.pie_enable: 1 -> 0 # /usr/local/bootstrap-openjdk17/bin/jar --version jar 17.0.1 Thanks a lot for leaving the fix. I have no idea how the ports framework might handle this dynamically but if it can it probably should... at least give a warning/error without trying to build. See this thread for more info about the issue. https://lists.freebsd.org/archives/freebsd-arm/2022-May/001340.html It is pretty easy to workaround the failure of bootstrap-openjdk17 by using "ELF_FEATURES= +noaslr:bin/*" in the port. See the linked mail for a more elaborate patch which only enables this on aarch64. But using this to build the java/openjdk17 build still fails in all kinds of internal executables with that same error during the openjdk17 build. I don't know how to workaround this in the ports framework. Plus -more important- why does this only happen on aarch64 and not amd64? I can reproduce this on an rpi4/8GB running: # uname -a FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-31e076d70b: Wed Mar 23 08:55:39 CET 2022 ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 Although my build jail is newer than the host. [00:00:01] Host OSVERSION: 1400053 [00:00:01] Jail OSVERSION: 1400055 I have no idea if something is broken in Java or in FreeBSD. (In reply to Ronald Klop from comment #7) Thanks for all the further information. Having changed to the sysctl openjdk17 did build fine for me on arm64: # /usr/local/openjdk17/bin/java --version openjdk 17.0.3 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-1) OpenJDK 64-Bit Server VM (build 17.0.3+7-1, mixed mode, sharing) Maybe we should just compile java with -fno-stack-protector (assuming that's the correct option) for the time being? These settings have something to do with it: [root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -version Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes [root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:CompressedClassSpaceSize=1m -version Error occurred during initialization of VM Could not allocate compressed class space: 4194304 bytes [root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:CompressedClassSpaceSize=10g -version size_t CompressedClassSpaceSize=10737418240 is outside the allowed range [ 1048576 ... 3221225472 ] Improperly specified VM option 'CompressedClassSpaceSize=10g' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. No value of CompressedClassSpaceSize works. But disabling CompressedClassPointers does: [root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:-UseCompressedClassPointers -version openjdk version "17.0.1" 2021-10-19 OpenJDK Runtime Environment (build 17.0.1+12-1) OpenJDK 64-Bit Server VM (build 17.0.1+12-1, mixed mode) reopen I have this problem on 13.1-STABLE as well as CURRENT. If I set kern.elf64.aslr.honor_sbrk=1 I can run the bootstrap-openjdk17 java at the command line, but it still fails with "Could not allocate compressed class space" when poudriere tries to build openjdk17. In its current state the port should be marked broken on aarch64. Created attachment 238371 [details]
git diff of java/openjdk17
Using this patch I can build openjdk17 using the current bootstrap-openjdk17 and the resulting pkg can run java/javac/javap without additional cmdline parameters or sysctl settings.
The patch effectively makes "-XX:-UseCompressedClassPointers" the default.
Tested on rpi4 aarch64/14 in a 13.1 jail.
I see it as a workaround but at least it gives a working JDK 17.
Created attachment 239493 [details]
Compressed pointers patch
I wondered if we might want to maintain the change as an extra patch rather than a sed command. Like we do for the PPC specific changes.
If you've got time, can you take a look at the attached patch and give it a try to see if it works?
Created attachment 239653 [details] Little fix on patch of Greg Lewis (In reply to Greg Lewis from comment #13) Your patch didn't apply when running "make patch". I recreated the patch by "make makepatch". Currently running a test build and will do a runtime test later today. Latest patch runs fine on 14/aarch64.
[root@rpi4 ~]# /usr/local/openjdk17/bin/java -XX:+PrintFlagsFinal -version | grep -i compr
size_t CompressedClassSpaceSize = 1073741824 {product} {default}
bool UseCompressedClassPointers = false {product lp64_product} {ergonomic}
bool UseCompressedOops = true {product lp64_product} {ergonomic}
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-1)
OpenJDK 64-Bit Server VM (build 17.0.5+8-1, mixed mode, sharing)
[root@rpi4 ~]# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-f4d3aa7490: Thu Dec 1 22:38:06 CET 2022 ronald@rpi4:/home/ronald/dev/freebsd/obj/home/ronald/dev/freebsd/src/arm64.aarch64/sys/GENERIC-NODEBUG arm64
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b39d592147e2c549d009e01dba155f14128e600f commit b39d592147e2c549d009e01dba155f14128e600f Author: Greg Lewis <glewis@FreeBSD.org> AuthorDate: 2023-01-24 05:15:43 +0000 Commit: Greg Lewis <glewis@FreeBSD.org> CommitDate: 2023-01-24 05:19:21 +0000 java/openjdk17: Fix the build on some aarch64 machines * Disable CompressedClassPointers on aarch64. This fixes the build on some aarch64 machines where it previously failed, e.g. RPI4, and doesn't seem to affect the build on others (AWS aarch64 hardware). This is based on and uses a patch initially created by ronald@ PR: 260187 Tested by: ronald@ java/openjdk17/Makefile | 5 +++++ ...ch-src_hotspot_share_runtime_arguments.cpp (new) | 21 +++++++++++++++++++++ 2 files changed, 26 insertions(+) Does this PR still have pending actions or can it be closed? (In reply to Ronald Klop from comment #17) It is still fails for any openjdk/aarch64 for vmware instance on apple m1/m2 configure: Output from java -version was: # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000000004a18ceec, pid=16643, tid=368704 # # JRE version: (17.0.1+12) (build ) # Java VM: OpenJDK 64-Bit Server VM (17.0.1+12-1, mixed mode, tiered, compressed oops, g1 gc, bsd-aarch64) # Problematic frame: # v ~BufferBlob::native signature handlers # # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.7-7-1/java.core # # An error report file with more information is saved as: # /wrkdirs/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.7-7-1/hs_err_pid16643.log # # configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1 (In reply to Dima Panov from comment #18) Ah. Interesting error. Although it is a different error than what this PR started with. Could you open a new PR for your error? Also because it seems specific to Apple M1/M2. (In reply to Ronald Klop from comment #19) Seems like related PR is already open https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265284 I think this is a different problem than the Apple Silicon problem and should be closed. |