I have two Macs: one is an M1, the other an M4, both with the same amount of memory. And on each I connect to a local VirtualBox VM using the Microsoft “Remote - SSH” extension as that's where the files/repos I need to access are.
Trying to use the VS Code SQL Developer extension with VirtualBox VMs and on the M1 it works, and on the M4 the extension appears stuck on Activating Oracle SQL Developer Extension for VS Code….
Environment details:
- VS Code Version: 1.100.2 (Universal)
- Oracle SQL Developer Extension for VS Code Version 25.1.1
- Oracle VirtualBox Version 7.1.6 r167084 (Qt6.5.3)
- Guest OS: Oracle Linux 8.10 for aarch64
- Guest Oracle Database installation: Oracle Database Free Edition 23.7
The VMs on each Mac are built with automation (Ansible) and hence should have the same software/versions. Inluding OS setup.
But on the M4 (only), each time VS Code tries to connect to its local VM and activate the SQL Developer extension, the JVM inside the VM crashes and creates a hs_err_pidxxxxx.log file.
And since the JVM crashes on activation, VS Code never receives the response it is expecting and consequently the extension appears to be hung on activating.
Java version is the same on the VMs on each machine.
Head of the hs_err_pidxxxxx.log file:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGILL (0x4) at pc=0x0000ffff88032c5c, pid=92618, tid=92619
#
# JRE version: (21.0.6+8) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.6+8-LTS-188, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j java.lang.System.registerNatives()V+0 java.base
#
# 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 /home/oracle/core.92618)
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- S U M M A R Y ------------
Command Line: -Dfile.encoding=UTF-8 -Djava.awt.headless=true --module-path=/home/oracle/.vscode-server/extensions/oracle.sql-developer-25.1.1-linux-arm64/dbtools/lib/modules/:/home/oracle/.vscode-server/extensions/oracle.sql-developer-25.1.1-linux-arm64/dbtools/sqlcl/lib/modules/ --add-opens=org.eclipse.parsson/org.eclipse.parsson=orajsoda -Djdk.module.main=com.oracle.dbtools.app com.oracle.dbtools.app/com.oracle.dbtools.app.DatabaseToolsApplication server --key-id dbtools-client-92363 --clientProcessId 92363 MIIBIjANBg<truncated>rwIDAQAB
Host: AArch64, 2 cores, 4G, Oracle Linux Server release 8.10
Time: Wed May 28 08:56:50 2025 MDT elapsed time: 0.015228 seconds (0d 0h 0m 0s)
--------------- T H R E A D ---------------
Current thread (0x0000ffff98028f70): JavaThread "Unknown thread" [_thread_in_native, id=92619, stack(0x0000ffff9ef23000,0x0000ffff9f121000) (2040K)]
Stack: [0x0000ffff9ef23000,0x0000ffff9f121000], sp=0x0000ffff9f11f0d0, free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
j java.lang.System.registerNatives()V+0 java.base
j java.lang.System.<clinit>()V+0 java.base
v ~StubRoutines::call_stub 0x0000ffff8802a158
V [libjvm.so+0x800db8] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x218
V [libjvm.so+0x7dceb0] InstanceKlass::call_class_initializer(JavaThread*)+0x27c
V [libjvm.so+0x7ddb54] InstanceKlass::initialize_impl(JavaThread*)+0x404
V [libjvm.so+0xd104f8] Threads::initialize_java_lang_classes(JavaThread*, JavaThread*)+0xe8
V [libjvm.so+0xd1264c] Threads::create_vm(JavaVMInitArgs*, bool*)+0x3ec
V [libjvm.so+0x88fe1c] JNI_CreateJavaVM+0x7c
C [libjli.so+0x438c] JavaMain+0x7c
C [libjli.so+0x79ec] ThreadJavaMain+0xc
C [libpthread.so.0+0x7950] start_thread+0x190
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.System.registerNatives()V+0 java.base
j java.lang.System.<clinit>()V+0 java.base
v ~StubRoutines::call_stub 0x0000ffff8802a158
siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x0000ffff88032c5c
...
Not sure what else to check or what might be the cause of this? The only difference I can find is the difference between one machine being an M1 and the other an M4 chip. Kernel setup is via the oracle-database-preinstall-23ai-1.0-4.el8.aarch64.rpm scriptlets. Perhaps this has changed over time resulting in a kernel configuration difference leading to this - IDK, just guessing.