Closed IoTInsights closed 4 years ago
It is not the best method, but please try the following
nrjavaserial/src/main/c/include/SerialImp.h
...
long get_java_var_long (JNIEnv *, jobject, char *, char *);
...
to
...
jlong get_java_var_long (JNIEnv *, jobject, char *, char *);
...
nrjavaserial/src/main/c/src/SerialImp.c
...
long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type )
{
long result = 0;
...
if ( !strcmp( type, "J" ) ) {
result = (long)( (*env)->GetLongField( env, jobj, jfd ) );
} else {
result = (size_t) ( (*env)->GetIntField( env, jobj, jfd ) );
}
...
to
...
jlong get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type )
{
jlong result = 0;
...
if ( !strcmp( type, "J" ) ) {
result = (jlong)( (*env)->GetLongField( env, jobj, jfd ) );
} else {
result = (size_t) ( (*env)->GetIntField( env, jobj, jfd ) );
}
...
rebuild native code
rebuild jar
I did the fix above and it works fine now. Should it also be using jint for the JNI int callback? I also forked and added some creates that allowed you to set additional parameters on instantiation and would like to fold those back in from my fork.
This fix works for me as well and fixes the crash under 64-bit Windows Java 10. @mizoguch-ken, why do you think it's "not the best method"? I assume that the issue is data truncation, because long
is 32-bit under 64-bit Windows, and it's converted to pointers elsewhere in the code. In this case, using jlong
to represent a Java long
, which is always 64-bit, does seem the correct solution to me.
Sorry for the late reply. There are two reasons why I think "not the best method". First, if it is decided to process a pointer, creating and using a pointer manipulation function is easy to understand and use at low cost. Second, it may be different from the author 's guess as it does not understand the source' s intent.
I believe I'm encountering the same problem. It seems to occur on Windows only with any version of Java newer than 8.
I've done some testing and this occurs on 64-bit Windows 10 Using AdoptOpenJDK versions 9, 10, and 11. It also occurs using Oracle's Java 10
There seems to be no problem using Java 8 on Windows. I've also had no problem with AdoptOpenJDK 11 on 64-bin Linux.
I am having the same issue on windows 7 with Oracle JDK/JRE 8 and 11. The simple example works, the issue i am having is that i am trying to read the DataInputStream in a seprarate thread
I attached a dump for both java 8 and 11 , perhaps it may help. hs_err_pid5316.log hs_err_pid11488.log
It is something which changed to jlong in dll of windows
Thanks for the update. I will try the jar provided in the zip this weekend to see if it works now.
On Tue, Jul 9, 2019 at 3:26 PM mizoguch-ken notifications@github.com wrote:
It is something which changed to jlong in dll of windows
nrjavaserial-3.15.0.zip https://github.com/NeuronRobotics/nrjavaserial/files/3368496/nrjavaserial-3.15.0.zip
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NeuronRobotics/nrjavaserial/issues/116?email_source=notifications&email_token=ADJN5YPK5UTZRUA6R26ZWLDP6SGYTA5CNFSM4ERQWCH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQIFTA#issuecomment-509641420, or mute the thread https://github.com/notifications/unsubscribe-auth/ADJN5YPASJXTXPAPVYAFL5TP6SGYTANCNFSM4ERQWCHQ .
Hi, are you gonna fix this issue in maven repository?
this issue is fixed and published in 3.19.0
Using the library with Java 9.0.4 causes a crash when reading data from the serial port. This also happens when I use the example from the README file. Switching to Java 8 fixes this crash.
Current thread (0x00000226ec844000): JavaThread "JavaFX Application Thread" [_thread_in_native, id=23688, stack(0x000000fa31400000,0x000000fa31500000)]
Stack: [0x000000fa31400000,0x000000fa31500000], sp=0x000000fa314faa60, free space=1002k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libNRJavaSerial.dll+0x753d] C [libNRJavaSerial.dll+0x7876] C 0x00000226c535921c
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.readArray([BII)I+0 j gnu.io.RXTXPort$SerialInputStream.read([BII)I+187 j gnu.io.RXTXPort$SerialInputStream.read([B)I+38