Upgrade from 2.10.4 to 2.11 causes jvm to crash

[patrick-dedication]

Hi, we just upgraded to version 2.11 no our jvm crashes when we interact with jSerialComm.

[NorbertSandor]

Maybe include some additional info, like the crash logs? Or which operation fails? Or on what operating system and environment?

[patrick-dedication]

Hi, sorry we are having some trouble in getting any information. We are using Java 17 on Windows 10. When we try it out on a Mac the error does not occur. Listing the available ports does not give the issue, but SerialPort.getCommPort port does.

Here what we see as far as module loading goes:

LoadedModule[47]=%TEMP%\jSerialComm\com-port-probe\2.11.0\jSerialComm.dll LoadedModule[48]=C:\Windows\System32\SETUPAPI.dll LoadedModule[49]=C:\Windows\SYSTEM32\DEVOBJ.dll

Here is an entry from the windows EventLog:

Faulting application name: java.exe, version: 17.0.10.0, time stamp: 0x55ce949a Faulting module name: jSerialComm.dll, version: 0.0.0.0, time stamp: 0x6620079b Exception code: 0xc0000409 Fault offset: 0x00011d9b Faulting process id: 0x1b9c Faulting application start time: 0x01da948e4c8b11c2 Faulting application path: %JAVA_HOME%\bin\java.exe Faulting module path: %TEMP%\jSerialComm\com-port-probe\2.11.0\jSerialComm.dll Report Id: a3174bcc-2e5d-4cb2-870b-74818372e9b1 Faulting package full name: Faulting package-relative application ID:

[patrick-dedication]

We just confirmed that this also happens with version 2.10.5

[hedgecrw]

Can you please post your exact call to SerialPort.getCommPort so I can try to reproduce on my end.

[rhaendel]

Hi @hedgecrw, the call simply is

SerialPort.getCommPort("COM4");

and "COM4" is one of six physical ports on that machine.

This is actually the first call to SerialPort we make. Before that, we just set System.setProperty("fazecast.jSerialComm.appid", "com-port-probe");

As Patrick mentioned, SerialPort.getCommPorts(); works. We noticed now, that the JVM does not crash if we put that in front of the getCommPort("COM4") call. Is that intended and our current way of use works by mistake?

[hedgecrw]

Ah, that's very helpful. I think I see where the issue is. Could you please test the following snapshot and see if the issue is resolved:

SNAPSHOT Version: 2.11.1-SNAPSHOT SNAPSHOT Direct Download Link SNAPSHOT Instructions

[rhaendel]

Unfortunately version 2.11.1-SNAPSHOT doesn't solve the issue. The JVM still crashes on SerialPort.getCommPort("COM4").

[hedgecrw]

Very odd, and I can't seem to reproduce this on my end. Does your Java application produce a crash dump when it crashes (or output anything in a terminal/command prompt)? I need to see something to indicate where exactly the crash is happening.

[sdorof1]

Confirmed issue on Windows 7 with java 17. Jvm does not procude any crash dump, just a windows with such info:

Сигнатура проблемы:
Имя события проблемы:   BEX
Имя приложения: java.exe
Версия приложения:  17.0.6.0
Отметка времени приложения: c1fb19a5
Имя модуля с ошибкой:   jSerialComm.dll
Версия модуля с ошибкой:    0.0.0.0
Отметка времени модуля с ошибкой:   6620079b
Смещение исключения:    00011dad
Код исключения: c0000417
Данные исключения:  00000000
Версия ОС:  6.1.7601.2.1.0.256.1
Код языка:  1049
Дополнительные сведения 1:  d32c
Дополнительные сведения 2:  d32c48b4e7f4c29ea288e49597f2471c
Дополнительные сведения 3:  7a6f
Дополнительные сведения 4:  7a6fca6139954f773a80861eed5dc6f7

Gradle reports next:

Caused by: org.gradle.process.internal.ExecException: Process 'command 'C:\jdk\jdk-17.0.6-i586-full\bin\java.exe'' finished with non-zero exit value -1073740777

System is

Operating system    Windows 7 6.1 (x86) 
CPU cores   2 cores 
Java runtime    BellSoft Liberica OpenJDK Runtime Environment 17.0.6+10-LTS 
Java VM BellSoft Liberica OpenJDK 32-Bit Client VM 17.0.6+10-LTS (mixed mode, sharing)  
Max JVM memory heap size    247.5 MiB   
Default charset UTF-8   

[hedgecrw]

Ah okay, I think the issue here is that this is a 32-bit PC (which should still work with no problem, but it's probably the least tested configuration we have). Let me try to get a VM set up with this to figure out what's going on.

[rhaendel]

Ah, our system is:

OS: 64-bit Windows 10 Enterprise 2016 LTSB (1607)
CPU: Intel(R) Core(TM) i3-7101E CPU @ 3.90GHz, 4 Cores

But there is a 32-bit JVM in use:

openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7)
OpenJDK Client VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode, emulated-client)

Accessing a 64-bit library using JNI in a 32-bit JVM seems quite a good reason.

[hedgecrw]

I was able to reproduce, but not able to find an actual root cause. It seems that lowering the optimization level (only for 32-bit Windows) solves the problem for me, but it's very strange. Please try the latest snapshot and see if this resolves it for you as well:

SNAPSHOT Version: 2.11.1-SNAPSHOT SNAPSHOT Direct Download Link SNAPSHOT Instructions

[szempy]

I had the same problem probably on a 32 bit environment and the snapshot solved my problem. Thank you.

[rhaendel]

@hedgecrw thank you very much! The latest snapshot solves the issue for us (@patrick-dedication and me).

[andrewoficial]

(Work OK)

(Problem)

(Work OK)

[rhaendel]

Just a little ping here. When is version 2.11.1 planned to be released? I'm hesitant about adding a snapshot version to our production code as a dependency.

[hedgecrw]

I'm out of the country until the end of next week, but I'll try to make a release at that time.