writeByte never ends in version 2.9.3

[haba-beton]

yesterday i upgraded from 2.9.2 to 2.9.3 but now the function writeByte never ends.
the program never return from writeByte after calling it, there is also no exception.
no problems with 2.9.2.

[tresf]

The native writeByte code differs between Windows and Unix systems. Which are you using? Also, which architecture are you on?

Also, providing the team a reproducible snippet that works on 2.9.2 but breaks on 2.9.3 is greatly appreciated.

Furthermore if you can help with the git-blame its appreciated. This is a volunteer-lead project, so blaming anything on a particular version isn't as helpful as blaming it on a particular Pull Request, commit or line number. 🍻

(I know I use the word "blame" here, but that's what Git uses 😅. It's not meant to be derogatory)

Here's the diff between versions:

v2.9.2...v2.9.3

[GMKennedy]

@haba-beton, if possible could you supply an example of your code that is experiencing this issue with the new version?

[haba-beton]

yes, of course, sorry for low infos.
The Problem is on Windows (10 21H1 AMD64).

Code:

public class Test {
  public static void main(String... args) throws Exception {
    SerialPort serialPort = new SerialPort("COM6");

    if (!serialPort.openPort()) {
      throw new Exception("COMPORT NOT OPEN.");
    }

    serialPort.setParams(SerialPort.BAUDRATE_115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE,false,false);

    System.out.println("A");
    serialPort.writeByte((byte)'\n');
    System.out.println("B");
    serialPort.writeBytes("VERSION\n".getBytes(StandardCharsets.US_ASCII));
    System.out.println("C");
  }
}

Console:

16:59:08.549 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_2012601084084063129: is 238281ms old
16:59:08.565 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_2039809358323635375: is 222517ms old
16:59:08.565 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_5326100828462893557: is 73513ms old
16:59:08.565 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_6309774244166163084: is 163283ms old
16:59:08.612 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_2012601084084063129: is 238344ms old
16:59:08.612 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_2039809358323635375: is 222564ms old
16:59:08.612 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_5326100828462893557: is 73560ms old
16:59:08.612 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_6309774244166163084: is 163330ms old
16:59:08.612 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Not deleting leftover folder C:\Users\User\AppData\Local\Temp\nativelib-loader_79200961179604210: is 0ms old
16:59:08.627 [main] DEBUG org.scijava.nativelib.NativeLibraryUtil - processor is INTEL_64 os.arch is amd64
16:59:08.627 [main] DEBUG org.scijava.nativelib.NativeLibraryUtil - architecture is WINDOWS_64 os.name is windows 10
16:59:08.627 [main] DEBUG org.scijava.nativelib.NativeLibraryUtil - architecture is WINDOWS_64 os.name is windows 10
16:59:08.627 [main] DEBUG org.scijava.nativelib.NativeLibraryUtil - platform specific path is natives/windows_64/
16:59:08.627 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - mappedLib is jssc.dll
16:59:08.627 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - URL is jar:file:/C:/Users/User/.gradle/caches/modules-2/files-2.1/io.github.java-native/jssc/2.9.3/54d5f19bc98f465f3319f2b9b328e89a96d5f13b/jssc-2.9.3.jar!/natives/windows_64/jssc.dll
16:59:08.627 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - URL path is file:/C:/Users/User/.gradle/caches/modules-2/files-2.1/io.github.java-native/jssc/2.9.3/54d5f19bc98f465f3319f2b9b328e89a96d5f13b/jssc-2.9.3.jar!/natives/windows_64/jssc.dll
16:59:08.627 [main] DEBUG org.scijava.nativelib.BaseJniExtractor - Extracting 'jar:file:/C:/Users/User/.gradle/caches/modules-2/files-2.1/io.github.java-native/jssc/2.9.3/54d5f19bc98f465f3319f2b9b328e89a96d5f13b/jssc-2.9.3.jar!/natives/windows_64/jssc.dll' to 'C:\Users\User\AppData\Local\Temp\nativelib-loader_79200961179604210\jssc.dll'
A

As you can see it stops after "A". Without any message. Version 2.9.2 shows A, B and C.

Thank you.

[tresf]

@haba-beton what's on the other end? I tested the above with a virtual port and it doesn't hang as you describe, but there's also no real hardware attached, so we'll start testing on actual hardware next.

[haba-beton]

on the other end is a Controllino Mini (arduino). It is a serial Port over USB.

[GMKennedy]

@haba-beton i just performed your unit test on a Windows 10 (20H2) with an Elegoo Arduino Uno, and it passes it with 2.9.3. same behavior on both 2.9.2 and 2.9.3. this was with running the Unit test in Intellij on OpenJDK8.

[haba-beton]

@GMKennedy this is misterious. I try'd it on another Windows 10 PC without success. After that i try it on an old Win 7, also without success. 2.9.2 working fine on both.

Because i am using the the lib as a maven dependency, i thought that i could try the version to find at:

https://github.com/java-native/jssc/releases/download/v2.9.3/jssc-2.9.3.jar

This jar seems to be compiled with > Java 8 because i got an error message 'java.lang.UnsupportedClassVersionError: jssc/SerialPort has been compiled by a more recent version of the Java Runtime (class file version 53.0)' when running it with OpenJDK 8. Then i try it with OpenJDK 11. The UnsupportedClassVersionError is gone but it also stops after 'A'.

Can you try to execute the sample in a separate project with the maven dependence or the above jar and not within you main project?

[tresf]

@haba-beton although we're not able to reproduce exactly, we have another product we're testing this with and we're experiencing issues there as well. So far, the issue seems to be isolated to Windows. That's all we know so far. We haven't changed much on the Windows side between releases, but thanks kindly for reporting this, we'll see what we can dig up.

[tresf]

Looks like a bug introduced in #91, specifically, we suppressed some compiler warnings and accidentally casted the BaudRate to a BYTE instead of a DWORD. We'll get new binaries out right away.

BEFORE:

jssc/src/main/cpp/windows/jssc.cpp

Line 104 in 1ee1666

dcb->BaudRate = static_cast<BYTE>(baudRate);

AFTER:

jssc/src/main/cpp/windows/jssc.cpp

Line 104 in dcd6d39

dcb->BaudRate = static_cast<DWORD>(baudRate);

[tresf]

the program never return from writeByte after calling it

serialPort.setParams(SerialPort.BAUDRATE_115200,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE,false,false);

@haba-beton the invalid cast was causing your BAURDATE_115200 to be casted to something else entirely. This means you may be able to replicate this behavior simply by setting the baud rate to something invalid using an older version.

In our tests, the behavior was completely different. The attached serial devices which we were sending data to were displaying an error.

Here's a version you can test locally on Windows 32-bit or Windows 64 bit:
jssc-2.9.4-SNAPSHOT.jar.zip