Java fatal error (SIGSEGV) using Pi4J Serial (related to native code)

[neorevx]

Hello,

my application is finishing abruptly and I believe the problem is related to Pi4J.

I Respond in #281 but I thought maybe no one would see it, so I decided to open this new issue.

I use Pi4J 1.2 for GPIO control for years without problems. So I had to use a serial to read data from a usb modem.
All tests went smoothly. But now I've seen that my system is experiencing an problem:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x766b68f8, pid=603, tid=1498412128

I run my app over 300 raspberry pi 3 / 3+ (literally). And I began to realize that several are presenting the problem. Both version of raspberry shows the problem.
Searching the internet I found the issue #281.
Reading the log report, I found records references linked directly to the native Pi4J library:

serial_callback_method+0 in /tmp/libpi4j659262621625719903.so at 0x65610000

See below:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x766b68f8, pid=603, tid=1498412128
#
# JRE version: Java(TM) SE Runtime Environment (8.0_65-b17) (build 1.8.0_65-b17)
# Java VM: Java HotSpot(TM) Client VM (25.65-b01 mixed mode linux-arm )
# Problematic frame:
# V  [libjvm.so+0x2e68f8]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

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

Current thread (0x65b3a800):  JavaThread "Thread-34" [_thread_in_vm, id=19312, stack(0x58d00000,0x59500000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000

...

  r6  = 0x00000000
0x00000000 is an unknown value

  r7  = 0x7696dfb8
0x7696dfb8: <offset 0x59dfb8> in /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/arm/client/libjvm.so at 0x763d0000

  r8  = 0x00000000
0x00000000 is an unknown value

  r9  = 0x766b6874
0x766b6874: <offset 0x2e6874> in /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/arm/client/libjvm.so at 0x763d0000

  r10 = 0x6562bc74
0x6562bc74: serial_callback_method+0 in /tmp/libpi4j659262621625719903.so at 0x65610000

  fp  = 0x594fed7c
0x594fed7c is pointing into the stack for thread: 0x65b3a800

  r12 = 0x0000deab
0x0000deab is an unknown value

  sp  = 0x594fed40
0x594fed40 is pointing into the stack for thread: 0x65b3a800

  lr  = 0x766b68f4
0x766b68f4: <offset 0x2e68f4> in /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/arm/client/libjvm.so at 0x763d0000

  pc  = 0x766b68f8
0x766b68f8: <offset 0x2e68f8> in /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/arm/client/libjvm.so at 0x763d0000

I believe the problem is related to the following fact:

The Serial port becomes unavailable while reading the data, and the Serial callback attempts to read a resource that does not exist.

Why?

I have two processes using Pi4J in Raspberry.

1. A process controls the connection using a USB modem. When the modem has some serious problems (hangs) I send a RESET or IOCTL command to restart the usb.
2. The second process (which is having problems) just reads some information from the modem. This process does not control USB, it does not reset the modem. However, it also does not know when the other process resets the modem.

Only the second process (2) crashs. The first process knows when the modem will no longer exist (due to the reset) and does not have an open connection at that time. Therefore, this process apparently has no problems.

The error may also be related to WiringPi. But I do not know. I use 'gpio version: 2.44' and 'gpio version: 2.46'.
I like Pi4J, I think it's a great project, and I would not want to have to use another library for serial access.

[pvsmian]

I am facing the same issue on a Pi3 B Plus running Raspberry Pi OS (32-bit) Lite release date 2020-08-20

The USB ports in question are either a BLE dongle or a modem - but neither should ordinarily become "unavailable" in my setup. The crash occurs sometime within 24 hours of a reboot.
hs_err_pid815.log