Closed Laivindur closed 3 years ago
Usually a SIGSEV 0xb error is associated with a low level driver conflict between the JVM and supporting native libraries.
Given
We realised that, if we disable hid4java service initialization or usb4java initialization in the production code, the USB events are handled by the remaining API with no errors. The JVM doesn't crash.
When both are up, there's a conflict at handling the USB events. Perhaps a race condition between both threads (service workers).
I'm inclined to think in this case that it's hidapi
and libusb
attempting to gain control over the USB interface and conflicting with each other. The question how to fix it.
One approach is to minimise the interaction. Perhaps having usb4java
handling attach/detach events and then hid4java
only opening specific devices that are classed as HID. You can turn off attach/detach event polling using ScanMode.NO_SCAN
in the HidSpecification
.
If a deeper dig is required, you probably want to review this answer on StackOverflow.
Any further info on this issue?
Hi Gary.
Yes, but I'm afraid of not to be capable of giving a detailed explanation of the fix.
We assumed what you suggested. Both native libs were competing since both were handling the USB attachments and detachments events. Maybe it was a lock, usb4java locking or reserving specific memory positions and hid4java causing the error at accessing to those sections or vice-versa.
For some obscure reason, it stopped to fail when we modified certain routines of the project' startup. Basically, we moved some Spring configuration code to a different stage of the bootstrapping and after the change, the issue was gone.
It's really rare but, to be honest, we have not delved into the problem. I just think you were right on your assumptions.
That said, it makes me think about something I told early about the possibility to make both Java Libs to work together within the same project. Maybe it's not a good idea.
Thanks @Laivindur. Given that this was resolved in your project (albeit with mysterious Spring magic) I'll mark it as closed. I've added more info to the wiki in the troubleshooting section to assist others in their application design.
See https://github.com/gary-rowe/hid4java/wiki/Troubleshooting#i-get-a-sigsegv-0xb-when-starting-up for details.
First of all, I'm unsure about how to report this bug and if it's really related to hid4java. The reasons for me to believe it are founded in some tests, core dumps analysis and different trials but, despite all the years working with Java, I have to admit that errors at such low level are very cryptic to me and I don't have a deep understanding of the JVM internals.
Bug Description In runtime, when any USB device is connected, the JVM crashes due to SIGSEGV
It happens in runtime when the app (Spring Boot app) already booted. Hid4JavaService is configured and started. By this time
This error never happens when hid4java is the only lib handling and managing USB devices. We have realised that the problem arises when it works alongside with usb4java.
How do we know? We realised that, if we disable hid4java service initialization or usb4java initialization in the production code, the USB events are handled by the remaining API with no errors. The JVM doesn't crash.
When both are up, there's a conflict at handling the USB events. Perhaps a race condition between both threads (service workers).
To Reproduce It's hard to say because it's happening in a very complex application, which is multi-thread and on top of this, there's SpringBoot. However, I have reproduced a very similar one, isolating both libs from Spring and the rest of the application.
For brevity, I will share my
pom.xml
for you to know what is involved and the respective versions of the libs.The Testing code
As you see, it's a copy of your original
UsbEnumerationExample
i have just added the code to initializeusb4java
. During the waiting time, if we plug any USB device, f(or example, I have used optical mice) it crashesDesktop (please complete the following information):
Additional context Add any other context about the problem here.