JNA support on Apple/M1 architecture

[micocube]

jline-jna error

com.sun.jna.LastErrorException: [14] Bad address
	at com.sun.jna.Native.invokeVoid(Native Method)
	at com.sun.jna.Function.invoke(Function.java:415)
	at com.sun.jna.Function.invoke(Function.java:361)
	at com.sun.jna.Library$Handler.invoke(Library.java:265)
	at com.sun.proxy.$Proxy19.ioctl(Unknown Source)
	at org.jline.terminal.impl.jna.osx.OsXNativePty.setSize(OsXNativePty.java:89)
	at org.jline.terminal.impl.AbstractPosixTerminal.setSize(AbstractPosixTerminal.java:68)
	at org.apache.felix.gogo.jline.ssh.ShellFactoryImpl$ShellImpl.run(ShellFactoryImpl.java:144)
	at org.apache.felix.gogo.jline.ssh.ShellFactoryImpl$ShellImpl.lambda$start$0(ShellFactoryImpl.java:124)
	at java.base/java.lang.Thread.run(Thread.java:829)
java.io.IOException: Pipe closed after 1 cycles
	at org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
	at org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:105)
	at com.mico.shell.ext.provider.refactor.PosixPtyTerminal.pumpIn(PosixPtyTerminal.java:209)
	at java.base/java.lang.Thread.run(Thread.java:829)

Code

    @Override
    public void setSize(Size size) throws IOException {
        winsize sz = new winsize(size);
        C_LIBRARY.ioctl(getSlave(), new NativeLong(TIOCSWINSZ), sz);
    }

Environment

• apple m1 mac book pro，Apple macOS 11.4 (Big Sur) build 20F71
• OS name: Mac OS X (JNA OS type: 0), arch: aarch64 (JNA arch: aarch64)
• java version：openjdk version "11.0.12" 2021-07-20 LTS
  OpenJDK Runtime Environment Zulu11.50+19-CA (build 11.0.12+7-LTS)
  OpenJDK 64-Bit Server VM Zulu11.50+19-CA (build 11.0.12+7-LTS, mixed mode)

[gnodet]

That could be related to #687 and wrong constant values on M1.
I should soon have access to a M1 to perform further tests.

[gnodet]

I've disabled JNA support on Apple/M1 with #721 until this can be fixed.

[marvin-enthus]

Hi,

I also stumbled over this issue today on M1 in combination with spring boot shell. After finding this thread I thought of overriding the constants as 'quick hack'.

➜  tmp cat <<EOF >TIOCGWINSZ.c
#include <stdio.h>
#include <sys/ioctl.h>

int main() {
	printf("TIOCGWINSZ: 0x%lx\n", TIOCGWINSZ);
	printf("TIOCSWINSZ: 0x%lx\n", TIOCSWINSZ);
	return 0;
}
➜  tmp make TIOCGWINSZ
cc     TIOCGWINSZ.c   -o TIOCGWINSZ
➜  tmp ./TIOCGWINSZ
TIOCGWINSZ: 0x40087468
TIOCSWINSZ: 0x80087467
➜  tmp file TIOCGWINSZ
TIOCGWINSZ: Mach-O 64-bit executable arm64

Ooops - the values are the same as for x64... Interesting.

After some further investigation: It seems to be related to the JRE used.
Some initial test results: (done with JLine 3.4 as this is the current version from the 'original' dependency)

• 17.0.3 (arm64) "JetBrains s.r.o." - "JBR-17.0.3+7-463.3-jcef 17.0.3" -> Working
• 11.0.15 (arm64) "JetBrains s.r.o." - "OpenJDK 11.0.15" (jbrsdk_dcevm-11.0.15) -> FAIL!
• 11.0.12 (arm64) "Azul Systems, Inc." - "Zulu 11.50.19" -> Working
• 11.0.9.1 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" -> Working

Yes, it's working for Arm and X86 running in emulation. It seems just (at least for me) the dcevm enabled JetBrains JDK-11 is producing this stacktrace....