Fazecast/jSerialComm

A fatal error has been detected by the Java Runtime Environment: EXCEPTION_ACCESS_VIOLATION (0xc0000005)

Tharrington86 opened this issue · 8 comments

I have a desktop application that uses serial communication via an Edgeport/1i to retrieve debug data from a device. When I click on the button to launch that feature the application crashes only if the Edgeport is connected to my PC. If the Edgeport is not connected, the feature loads but obviously there is no data to be retrieved. I was using v2.9.2 but have upgraded and 2.9.3 displays the same behavior.

hs_err_pid23528.log
hs_err_pid24788.log

As an experiment, I incrementally downgraded versions until I found one that initialized without crashing the JVM. Version 2.7.0 seems to be working properly. It will at least find the available ports (have not tried communicating across one yet). I haven't had time to look into the differences in the code base yet but it appears that starting with 2.8.0 is where the problem surfaces.

I'm unfortunately out of town until after the new year, so I won't be able to look into this until then. If you have the bandwidth, there is some sample native enumeration code for Windows under src/test/c/testEnumerateWindows.c. This might be useful in determining which exact line is causing the crash.

@hedgecrw I was unable to solve the problem and I don't have bandwidth currently to continue with trouble shooting efforts. I will use the downgraded version for now but hope to see a fix soon.

CJure commented

I had same problem with [2.0.0,3.0.0). But only when there was a lot of traffic on Rx line. If I am using protocol like Modbus it works OK, But if I use some other device with custom protocol that spits a lot of data without stooping, I get same error.
For me it was same solutions as for @ Tharrington86 to downgrade to version 2.7.0, So thank you for that.

@CJure, please try out the newest version of the library (currently v2.10.1). There have been a number of changes under-the-hood to mitigate the constant allocation/reallocation of memory on the native side of the library. Thanks!

This should be solved with release v2.10.2. We are now allowing the JVM to allocate its own memory if necessary which should negate any issues with native memory allocation or native memory accesses.