EXCEPTION_ACCESS_VIOLATION : JVM crashes on windows 10 in the jssc lib at : jssc.SerialNativeInterface.openPort

[atawre]

I was using jssc 2.8.0 and java 8. Need to switch to Java 11 for project requirement.
After everything is ported the jssc library seems to cause jvm to crash on window 10.
(Log is attached)

---------------  S U M M A R Y ------------

Command Line: -Dvisualvm.id=622907326716200 --module-path=C:\Program Files\Java\javafx-sdk-11.0.2\lib --add-modules=javafx.controls,javafx.fxml --illegal-access=warn --add-modules=javafx.base,javafx.graphics --add-reads=javafx.base=ALL-UNNAMED --add-reads=javafx.graphics=ALL-UNNAMED -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\lib\idea_rt.jar=50486:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\bin -Dfile.encoding=UTF-8 App

Host: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 8 cores, 7G,  Windows 10 , 64 bit Build 17763 (10.0.17763.1158)
Time: Thu May 21 00:17:24 2020 Atlantic Daylight Time elapsed time: 18 seconds (0d 0h 0m 18s)

---------------  T H R E A D  ---------------

Current thread (0x0000026644350000):  JavaThread "Timer-0" [_thread_in_native, id=19756, stack(0x000000b036000000,0x000000b036100000)]

Stack: [0x000000b036000000,0x000000b036100000],  sp=0x000000b0360feb00,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x000000007110b5db

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jssc.SerialNativeInterface.openPort(Ljava/lang/String;Z)J+0
j  jssc.SerialPort.openPort()Z+65
j  Serial.attemptDongleConnect()V+72
j  Serial$3.run()V+45
j  java.util.TimerThread.mainLoop()V+221 java.base@11
j  java.util.TimerThread.run()V+1 java.base@11
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000000004c095fe6

There is similar bug reported earlier - https://bugs.openjdk.java.net/browse/JDK-8203772
However, this was closed as jssc issue.
I am using openjdk 11. Wondering this is fixed. Since 2.9.0 mentions following in the fixes section.
Fixed hard crash on Windows using JDK11

hs_err_pid18016 (1).log

[tresf]

Unfortunately the upstream bug report where this was originally reported has vanished, but this specific bug has since been patched and available for immediate download here: https://github.com/java-native/jssc/releases

[atawre]

I am using the same jar that you mentioned. https://github.com/java-native/jssc/releases/download/v2.9.0/jssc-2.9.0.jar
Still seeing the issue. Would you need more information around this?

[tresf]

The aforementioned jar is tested and working on AdopOpenJDK11 (all releases), so I'm uncertain as to whether or not this can be fixed for OpenJDK11 from java.net but I'll leave it open for now.

Note, it was tested on XP, 7, 10 as well as Solaris, MacOS 10.9+ and various Linuxes.

Related: adoptium/adoptium-support#76

[atawre]

I am seeing this on AdoptOpenJDK too.

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000007110b5db, pid=15956, tid=9540
#
# JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  0x000000007110b5db
[hs_err_pid15956.log](https://github.com/java-native/jssc/files/4664053/hs_err_pid15956.log)

[tresf]

Does it occur on a second Windows 10 machine? If so, exact environment will help. If not, it's likely specific to something with your machine.

[atawre]

Will update you shortly. I have only one machine with me in WFH mode.

[atawre]

Here is the result from my colleagues machine. The log is attached. Same result.
hs_err_pid15244.log

[atawre]

Here is one more log from 3rd machine. Amazon's Corretto implementation of Java 11.

3rd-log.txt

[tresf]

@atawre thanks for this information and for testing it on so many different JVMs. I'm a bit puzzled as to the various crashes. I have JSSC 2.9.1 library running on many (tens of thousands of) Windows 10 machines for an open-source commercial project that I operate.

This leads me to suspect a few things:

1. We're using the API differently
   -- OR --
2. The crash is brand new with something recent (e.g. a Windows update)

For starters, can you share a Java code snippet which reproduces it? Additionally, if you can share the exact Windows information (32-bit vs. 64-bit and precise Windows 10 build version). This will be helpful in understanding scope.

[atawre]

hs_err_pid15548.log

PFA one more log attached. Here is the link for crash dump (1.5gb) https://gofile.io/d/SPsioa

[tresf]

Also, the logs suggest it's happening from IntelliJ, is this just how you're debugging it? I noticed a few things that differ but namely:

1. Your PATH suggests AdoptOpenJDK is installed in C:\Program Files\Java which I believe to be non-standard
2. Your PATH contains entries for JavaFX, which I believe to be non-standard.

Historically, a polluted PATH is the source of many JVM crashes. If you mimic this environment on all machines affected, it may be producing the same results.

Unpolluting the PATH is tricky, a lot of apps use it. As a test, you could backup your current PATH and see if the crash goes away when it's empty, adding them back in until it reproduces.

[atawre]

machine info.txt

I will update you more PATH thing. Yes, I am using intellij (debug) to run it.
Here is sample code that is failing. The same file have machine details too.

[tresf]

You can place code directly inside github using ```java tags.

Extracted, quoting:

// It fails at port.openPort
// SSTSerialPort  is just a derivative of SerialPort
// transitionToDongleConnected keep internal state, so nothing much there too.
private void attemptDongleConnect() {
    if (dongleConnectionState == DongleConnectionState.DongleConnected)
        return;

    if (isSimulatingDongleConnection()) {
        transitionToDongleConnected();
    } else {
        closePort();

        String[] ports = SerialPortList.getPortNames();

        if (ports.length > 0) {

            port = new SSTSerialPort(ports[0], isInRecordMode);

            try {
                log.info("Attempting to open port.");

                transitionToDongleConnected();

                boolean portOpened = port.openPort();
                port.setParams(CommunicationConstants.BAUD_RATE, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
                port.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT);
                port.addEventListener(this, SerialPort.MASK_RXCHAR + MASK_CTS);

                log.info("Port Opened? " + portOpened);

                if (portOpened) {

                    if (dongleConnectionState == DongleConnectionState.NoDongleConnected)
                        transitionToDongleConnected();

                    SerialSend.sendListCommand(port);
                    System.out.println("SENDING LIST COMMAND");
                }

            } catch (Exception ex /*| SerialPortException spe*/ ) {
                port = null;
                transitionToDongleDisconnected();

                log.error("Error opening port", ex);
            }
        }
    }
}

[tresf]

The code make several API calls which are not provided. After ruling out the PATH issues, please prepare a basic reproducible example, e.g. https://stackoverflow.com/help/minimal-reproducible-example

[atawre]

I have removed earlier java version. Installed AdoptOpenJDK from msi package (java is in standard path.) Here is the mimimal code that I have on a button click, which fails exactly same.

@FXML
private void btnStartStop_clicked() {
    String[] ports = SerialPortList.getPortNames();

    if (ports.length > 0) {

        SerialPort port = new SerialPort(ports[0]);
        try {
            boolean portOpened = port.openPort();
            System.out.println(portOpened);
        } catch (SerialPortException e) {
            e.printStackTrace();
        }
    }
}

All the calls on this button click are using standard jsst methods/classes, nothing from out project.
Also see the path details in the attachment. Not sure if call leading to button event affect this, which it shouldn't.

hs_err_pid4456.log

[tresf]

Attached is a test which runs fine using IntelliJ on my machine:

• Winver: 19041.208
• AdoptOpenJDK 11.0.7 64-bit
• JSSC 2.9.1 from this repo
• Your code

JsscTest.zip

I have Oracle JDK8 installed as well, but the IDE is configured to use AdoptOpenJDK11.

The output is the following:

  "C:\Program Files\AdoptOpenJDK\jdk-11.0.7.10-hotspot\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\lib\idea_rt.jar=62252:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\bin" -Dfile.encoding=UTF-8 -classpath C:\Users\Owner\Desktop\JsscTest\out\production\Desktop;C:\Users\Owner\Desktop\JsscTest\lib\jssc-2.9.1.jar Main
  SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
  SLF4J: Defaulting to no-operation (NOP) logger implementation
  SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
+ COM1 Opened: true

  Process finished with exit code 0

All the calls on this button click are using standard jsst methods/classes, nothing from out project.

I would expect a unit-test to be a plain static void main with no other depends. I'm not sure if this would influence the behavior.

I've also noted your Windows version is older. This may or may not be relevant.

[atawre]

The tests you supplied work. Not sure why it doesn't through my module. If you have a debug version of the jar ( dll with debug symbols) I can generate memory dump, if that helps. Note:All of this code worked for years with jdk8.

[tresf]

JDK8 didn't pollute the path in the same fashion, so there's that. In regards to debug symbols, the project doesn't offer a precompiled build with them yet. A build could be created using maven and toggling on the debug flags, but assuming you're building using something like MSVC, it may not even crash since the .dll files are built using the mingw cross-compiler.

If using cmake directly, it's -DCMAKE_BUILD_TYPE=Debug. If you're using Maven, it requires a change on one of these two lines:

MSVC 64-bit:

jssc/pom.xml

Line 405 in 6d09752

<cmake.build.args>--config Release</cmake.build.args>

MSVC 32-bit:

jssc/pom.xml

Line 420 in 6d09752

<cmake.build.args>--config Release</cmake.build.args>

I'm still not sure if this is going to help though. If mine crashes and yours doesn't, you should be looking at the environment, not the debugger in my opinion.

[tresf]

As a courtesy, I can take a look at the offending IntelliJ project to see if the crash happens on my PC. You can email it to me, tres.finocchiaro@gmail.com.

[tresf]

Hi, if you're able to send the project over please let me know. Otherwise, I'll close this as unreproducible.

[dan-3lliott]

I'm having this same exact problem with a project that uses JavaFX. I tried an example with a fresh project containing an unaltered PATH and it made no difference.

[tresf]

@dan-3lliott If you can whip up a small unit test, please share.

[szebedy]

@tresf I solved this exact same problem by updating my jssc version to 2.9.1. Would you mind adding this version to the central maven repository for easier usage? https://mvnrepository.com/artifact/org.scream3r/jssc

[tresf]

@szebedy thanks for pointing that out. We don't have permission to push to the org.scream3r repository but even if we were to create our own, the Maven experts that used to help with this fork have since left. If you or someone you know can help with this effort, we'd be elated.

See also #23

[legoethals]

A customer of us had the same problem when upgrading from JRE 1.8.0_251-B08 to 1.8.0_271 using org.scream3r:jssc:2.8.0
Using io.github.java-native:jssc:2.9.2 did NOT solve the problem, downgrading back to 1.8.0_251 did solve the problem.
The software runs on Windows 10 Enterprise x64 Version 10.0.18362.1082

[Puccet]

We have exactly the same problem, the fact there's no 2.9.1 on maven is critical

[pietrygamat]

We have exactly the same problem, the fact there's no 2.9.1 on maven is critical

@Puccet, just to make it clear, 2.9.1 may not be on Maven Central, but 2.9.2 of this fork is - so when you say you have the same problem, do you mean it happens with latest version that is on Maven, but not with 2.9.1?

[Puccet]

@pietrygamat No, I missed the 2.9.2, just set in the pom and now all seems to work properly, Thanks a lot!!

[MarkJeronimus]

Just chiming in that JSSC 2.9.2 on Java 1.8.0_271 for Windows x86 works fine for me.

[krzysgl]

Please have a deeper look. Happening widely. 2.9.2 brefore, 2.9.4 downloaded today too. OpenJDK11, Amazon Coretto JDK11 fresh, updated installs. Many machines. No matter Intel or Amd. Windows 10 or 11 fresh installs with all updates. Just the first attempt to open a port crashes the JVM.
I started using JSSC quite a long time ago and I still keep my customers on Oracle JDK8 because of this bug.
Many thanks for any help!

[tresf]

Please have a deeper look.

This is an open source library, worked on by volunteers (like you!), the code and its build tools are open, I encourage anyone to spearhead this. The steps to reproduce this problem were never able to be reproduced on a secondary machine.

Generally, these types of crashes can occur when there's a DLL conflict or if the program is compiled with certain optional CPU features.

Since this is a fork of an unmaintained project, I ask anyone that's experiencing this issue to help identify its cause. Instructing internet stranger to look into something sours the open source model.

[tresf]

To add some more context, I forked this library here for this exact issue because I bundle JSSC with a Java application that I maintain and is currently deployed to hundreds of thousands of Windows computers and this issue hasn't been reported there.

• Is the issue identical between downloaded versions from GitHub and Maven?
• Have you ruled out something environmental is not at play? Currently, the app I bundle it with uses Adoptium OpenJDK 64-bit. If a fresh install of Windows (not a custom image, not a slipstream, preimaged or remote deployed machine) exhibits this crash with Adoptium 64-bit that information will be helpful to know.

[tejumolamann]

Hey Everyone, I was having the exact same problem at work, 'EXCEPTION_ACCESS_VIOLATION'. My machine is Windows 11, Java 8, and JSSC 2.8. What worked for me is I switched from JSSC-2.8 to JSSC-2.9.2. The problem never came up again.

[krzysgl]

I should probably leave a status... So this fork fixes the problem in the 2.9+ on all configurations I mentioned. Lesson learned.
Jssc is quite popular and you might get an old version/fork coming with some library that you think is totally unrelated. In my case it was not even a 2nd level dependency collision - jssc 2.8 was smuggled inside a Jpos wrapper and I only learned that when checking native binaries.
So, if you get the exceptions mentioned - check what are you actually deploying - including binary files hash.

[pietrygamat]

I think this can be considered done.