Open sxa opened 3 years ago
This assertion means there is a virtual memory allocation using omrvmem_reserve_memory_ex
with requested memory size not aligned (rounded) to requested memory page size.
And there is very confusing: is it really aarch64 or x86? JDK reference suggests this is x86
is it really aarch64 or x86?
Not sure if "it" refers to the JDK or the machine in that question... As per the title of this issue it's the x64 binary running via the emulation later that Apple provide on their aarch64 systems. So the hardware is aarch64:
administrator@test-macstadium-macos11-arm64-2 ~ % uname -a
Darwin test-macstadium-macos11-arm64-2.adoptopenjdk.net 20.0.0 Darwin Kernel Version 20.0.0: Sun Jun 14 21:36:36 PDT 2020; root:Bridge_xnu-7090.111.5.2~1/RELEASE_ARM64_T8020 arm64
ok, is it possible to get system core?
there is not so much we can get from provided data:
1XMCURTHDINFO Current thread
3XMTHREADINFO "(unnamed thread)" J9VMThread:0x000000000837E700, omrthread_t:0x00007FC6CB00E450, java/lang/Thread:0x0000000000000000, state:R, prio=0
3XMTHREADINFO1 (native thread ID:0xECE45DF, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00000000)
3XMTHREADINFO2 (native stack address range from:0x000000020D878000, to:0x000000020D8F8000, size:0x80000)
3XMCPUTIME CPU usage total: 0.104668000 secs, current category="System-JVM"
3XMTHREADINFO3 No Java callstack associated with this thread
3XMTHREADINFO3 No native callstack available for this thread
15:05:15.923731000 0x837e700 j9shr.1293 Event RMI locateROMClass: Locate succeeded. Returning 0x2f57a878. FoundAtIndex=0. StaleCPEI=0x0. Locate request for ROMClass java/lang/Math from helper ID 0 with cpeIndex 4294967295.
15:05:15.923732000 0x837e700 j9shr.1297 Event CM findROMClass: class java/lang/Math found at address 0x1e253498 with classpath index 0. The classpath id is 0.
15:05:15.923733000 0x837e700 j9vm.80 Event ROM class 0x1e253498 is named java/lang/Math
15:05:15.923733000 0x837e700 j9vm.1 Entry >Create RAM class from ROM class 0x1e253498 in class loader 0x7fc6cb06be68
15:05:15.923748000 0x837e700 j9vm.353 Exit <loader 0x83d1900 class 0X20d875d68 attemptDynamicClassLoad exit
15:05:15.923748000 0x837e700 j9vm.2 Exit <Created RAM class 0x83d1900 from ROM class 0x1e253498
15:05:15.923751000 0x837e700 j9vm.222 Event sendClinit - class java/lang/Math
15:05:15.923757000 0x837e700 j9vm.222 Event sendClinit - class java/lang/Float
15:05:15.923915000 0x837e700 omrport.0 Assert * ** ASSERTION FAILED ** at /Users/jenkins/workspace/build-scripts/jobs/jdk11u/jdk11u-mac-x64-openj9/workspace/build/src/omr/port/osx/omrvmem.c:345: ((0 == ((uintptr_t)(params->byteAmount) % (uintptr_t)(params->pageSize))))
At the moment I don't believe my system is generating it properly, but Daryl told me that @knn-k would be able to take a better look since he has an Apple Silicon mac
I expect the same issues that prevent generation of core files on x64 systems will also prevent them on Apple Silicon. See AdoptOpenJDK/openjdk-build#1778.
I cannot reproduce the failure. The x64 binary runs successfully on Apple Sillicon Mac mini (macOS Big Sur 11.1) as shown below, with or without the JIT.
% jdk-11.0.9+11-jre/Contents/Home/bin/java -Xint -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.23.0, JRE 11 Mac OS X amd64-64-Bit Compressed References 20201130_830 (JIT disabled, AOT disabled)
OpenJ9 - 0394ef754
OMR - 582366ae5
JCL - 3b09cfd7e9 based on jdk-11.0.9+11)
% jdk-11.0.9+11-jre/Contents/Home/bin/java -Xjit:count=0 -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.23.0, JRE 11 Mac OS X amd64-64-Bit Compressed References 20201130_830 (JIT enabled, AOT enabled)
OpenJ9 - 0394ef754
OMR - 582366ae5
JCL - 3b09cfd7e9 based on jdk-11.0.9+11)
Java -version output
This is from the latest JDK11 GA i.e. OpenJDK11U-jre_x64_mac_openj9_11.0.9_11_openj9-0.23.0.tar.gz (Same occurs with JDK8)
Summary of problem
Crashes, as per the above message (which was done with
-Xint
but it does the same without that tooDiagnostic files
macos_aarch64_jdk11crash.tar.gz
NOTE: The Hotspot JVM does not fail in the same way and is able to run
java -version
and at least attempt the test suites