search

balena-os / balena-raspberrypi

Balena support for RaspberryPI boards
https://www.balena.io/os/
Apache License 2.0
193 stars 74 forks source link

Issues with 64bit OpenJDK 11 images #325

Open sgammon opened 5 years ago

sgammon commented 5 years ago

The new 64bit images are pretty cool, although I haven't been able to get them to work with OpenJDK 11 (or any JDK 11 for that matter).

Everything seems to fail with the following message:

qemu: Unsupported syscall: 168
Error occurred during initialization of VM
getcpu(2) system call not supported by kernel

It's pretty easy to repro, and it seems to be an issue regardless of OS - I have been able to reproduce the issue on debian, and ubuntu (alpine doesn't have a JDK 11 image yet, wink wink). Installing the OpenJDK myself in a clean ubuntu-only image also doesn't seem to work.

Here is the output and steps to reproduce the issue:

(For Debian Sid / JDK 11)

> docker run --rm -it balenalib/raspberrypi3-64-debian-openjdk:11-sid java -version
Unable to find image 'balenalib/raspberrypi3-64-debian-openjdk:11-sid' locally
11-sid: Pulling from balenalib/raspberrypi3-64-debian-openjdk 
[... image pull omitted ...]
Digest: sha256:1aa532b54833ed7f54b774929e4674fffdf6a10f2e26cf1d375721b2e039a6db
Status: Downloaded newer image for balenalib/raspberrypi3-64-debian-openjdk:11-sid
qemu: Unsupported syscall: 168
Error occurred during initialization of VM
getcpu(2) system call not supported by kernel

(For Ubuntu Bionic / JDK 11)

> docker run --rm -it balenalib/raspberrypi3-64-ubuntu-openjdk:11-bionic java -version
qemu: Unsupported syscall: 168
Error occurred during initialization of VM
getcpu(2) system call not supported by kernel
floion commented 5 years ago

@nghiant2710 does this ring any bell?

shaunmulligan commented 5 years ago

@sgammon do you get the same error is you use the official docker aarch64 images ?

sgammon commented 5 years ago

this is what i get running java -version on different versions of aarch64/openjdk:

works fine for JDK 8 (8-jdk):

Unable to find image 'aarch64/openjdk:8-jdk' locally
8-jdk: Pulling from aarch64/openjdk
Digest: sha256:7b6e57004a14521deade41f2006add8cf4b1c20862c25cf9a6010df70c07865e
Status: Downloaded newer image for aarch64/openjdk:8-jdk
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-1~bpo8+1-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

starts failing at JDK 9 (9-jdk):

Unable to find image 'aarch64/openjdk:9-jdk' locally
9-jdk: Pulling from aarch64/openjdk
[... pull omitted ...]
Digest: sha256:a7348b0097bb13b0061b3e983b9ba112a3906daed62912c1de1b197c7bcf8500
Status: Downloaded newer image for aarch64/openjdk:9-jdk
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000004000f5adf0, pid=1, tid=30
#
# JRE version: OpenJDK Runtime Environment (9.0) (build 9-Debian+0-9b168-1)
# Java VM: OpenJDK 64-Bit Server VM (9-Debian+0-9b168-1, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x440df0]  CompileBroker::compiler_thread_loop()+0x118
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid1.log
Compiled method (c1)     921   42       3       java.util.HashMap::putVal (300 bytes)
 total in heap  [0x0000004012742c10,0x00000040127447a0] = 7056
 relocation     [0x0000004012742d80,0x0000004012742f10] = 400
 main code      [0x0000004012742f40,0x0000004012744140] = 4608
 stub code      [0x0000004012744140,0x00000040127442d8] = 408
 metadata       [0x00000040127442d8,0x0000004012744340] = 104
 scopes data    [0x0000004012744340,0x0000004012744558] = 536
 scopes pcs     [0x0000004012744558,0x0000004012744738] = 480
 dependencies   [0x0000004012744738,0x0000004012744740] = 8
 nul chk table  [0x0000004012744740,0x00000040127447a0] = 96
Compiled method (c1)     926   42       3       java.util.HashMap::putVal (300 bytes)
 total in heap  [0x0000004012742c10,0x00000040127447a0] = 7056
 relocation     [0x0000004012742d80,0x0000004012742f10] = 400
 main code      [0x0000004012742f40,0x0000004012744140] = 4608
 stub code      [0x0000004012744140,0x00000040127442d8] = 408
 metadata       [0x00000040127442d8,0x0000004012744340] = 104
 scopes data    [0x0000004012744340,0x0000004012744558] = 536
 scopes pcs     [0x0000004012744558,0x0000004012744738] = 480
 dependencies   [0x0000004012744738,0x0000004012744740] = 8
 nul chk table  [0x0000004012744740,0x00000040127447a0] = 96
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
qemu: uncaught target signal 6 (Aborted) - core dumped

AFAIK there is no aarch64 official image with a JDK 11 in it.

sgammon commented 5 years ago

hey guys, any news on this? @floion, @nghiant2710, @shaunmulligan

shaunmulligan commented 5 years ago

@sgammon if its failing on aarch64/openjdk:9-jdk it sounds like its an issue upstream with the openjdk folks, have you raised an issue with them for it? Currently we don't have much more to go on and it looks as though this may need some specific knowledge of JRE and its internals.

One other question is does this happen outside of qemu, just doing the balene pull aarch64/openjdk directly on the RPI3?