bc-java icon indicating copy to clipboard operation
bc-java copied to clipboard

cpu_variant prober doesn't work correctly for AArch64 on GCP and OCI

Open jingyuanliang opened this issue 11 months ago • 1 comments

On GCP T2A machine (https://cloud.google.com/blog/products/compute/tau-t2a-is-first-compute-engine-vm-on-an-arm-chip, but NOT C4A https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu which works fine), as well as OCI A1 machine (https://www.oracle.com/cloud/compute/arm/, did NOT try A2 machine), Jira 10.2.0+ (introduced https://confluence.atlassian.com/jirasoftware/jira-software-10-2-x-upgrade-notes-1455425770.html, running using the official container shipped with bouncy-castle-java-lts 2.73.7) crashes with SIGILL.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000ffff6c18aed0, pid=7, tid=63
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.14+7 (17.0.14+7) (build 17.0.14+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.14+7 (17.0.14+7, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# C  [libbc-lts-neon-le.so+0xaed0]  gcm_init+0x880
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /var/atlassian/application-data/jira/core.7)
#
# An error report file with more information is saved as:
# /var/atlassian/application-data/jira/hs_err_pid7.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

It doesn't crash when I do either:

  • Downgrade to Jira 10.1.2 (which doesn't exercise the new encryption)
  • Downgrade bouncy-castle to 2.73.3 (before 2.73.4 introduced hardware acceleration)
  • Set -Dorg.bouncycastle.native.cpu_variant=java

jingyuanliang avatar Feb 18 '25 13:02 jingyuanliang

I also just encountered this issue on an AWS Graviton2 (t4g.large) instance while testing. The provided workaround of setting -Dorg.bouncycastle.native.cpu_variant=java worked for me.

clemens-oppenauer avatar Feb 19 '25 16:02 clemens-oppenauer