search

gary-rowe / hid4java

A cross-platform Java Native Access (JNA) wrapper for the libusb/hidapi library. Works out of the box on Windows/Mac/Linux.
MIT License
229 stars 71 forks source link

hid4java Device Scanner crashes on mac after 30-40 seconds #37

Closed mgerlach-klick closed 4 years ago

mgerlach-klick commented 8 years ago

Hi Gary,

Thanks for this great library! It works great except that as soon as I connect to a HID device (through HidDevice#getHidDevice) my JVM commits suicide after 30-40 seconds, complaining about a SIGSEV in the "hid4java Device Scanner" daemon thread.

Do you have any idea what that could be? I'm attaching a recent crash log, that should have all the relevant information. Thanks! hs_err_pid40191.txt

mgerlach-klick commented 8 years ago

I should have read the FAQ better, my problem sounds a lot like the "SIGSEV (0xb)" question. That said, I'm afraid the answer doesn't tell me much and I'm at a loss as to what I'm doing wrong. I'm having a very minimal script that I'm trying to run. I apologize, it's in Clojure, I hope that's not an issue:

(ns cheekyled.core
  (:gen-class)
  (:import [org.hid4java HidDevice HidDeviceManager HidManager HidServices HidServicesListener]
           [org.hid4java.event HidServicesEvent]))

(defn hid-services []
  (let [p (proxy [HidServicesListener] []
          (hidDeviceAttached [e] (prn 'ATTACHED e))
          (hidDeviceDetached [e] (prn 'DETACHED e))
          (hidFailure [e] (prn 'FAILURE e)))
        services (HidManager/getHidServices)]
    (.addHidServicesListener services p)
    services))

(defn attached-devices []
  (.getAttachedHidDevices (hid-services)))

(defn write [device message packet-length report-id]
 (.write device message packet-length (byte report-id)))

(defn find-led []
  (let [vendor 0x1d34
        device 0x0013]
    (.getHidDevice (hid-services) vendor device nil)))

(defn with-led [f]
  (let [led (find-led)]
    (f led)
    (.close led)))

(defn write-diamond [led]
  (let [diamond [[0x00, 0x00, 0xFF,0xFE,0xFF, 0xFF,0xFD,0x7F,],
                 [0x00, 0x02, 0xFF,0xFB,0xBF, 0xFF,0xF7,0xDF,],
                 [0x00, 0x04, 0xFF,0xFB,0xBF, 0xFF,0xFD,0x7F,],
                 [0x00, 0x06, 0xFF,0xFE,0xFF,]]]
    (doseq [row diamond]
      (write led (byte-array row) 8 0))))

This works if I run a (with-led (find-led) write-diamond) but crashes 30 seconds later. I can't see a difference to your UsbHidTrezorV1Example that would explain to me what you mean by your FAQ answer.

gabrielpaim commented 8 years ago

Hi there,

@mgerlach-klick just to complement, I also had some issues with this SIGSEV crash on my mac (OSX 10.11.3). As I don't need the automatic scanning right now, I didn't investigate further the problem and I ended up using a lower level scan process (using the hidApi enumeration). However, I'm willing to cooperate.

@gary-rowe any plans for a next release? :+1: Thanks again.

mgerlach-klick commented 8 years ago

@gabrielpaim Any chance you have a code snippet somewhere that I could have a look at?

mgerlach-klick commented 8 years ago

Nevermind, I figured it out! This now works!

(ns cheekyled.core
  (:gen-class)
  (:import [org.hid4java HidDevice HidDeviceManager HidManager HidServices HidServicesListener]
           [org.hid4java.event HidServicesEvent]
           [org.hid4java.jna HidApi]))

(defn write [device message packet-length report-id]
 (.write device message packet-length (byte report-id)))

(defn find-led []
  (let [vendor 0x1d34
        device 0x0013]
   (HidDevice. (HidApi/enumerateDevices vendor device))))

(defn with-led [f]
  (let [led (find-led)]
    (.open led)
    (f led)
    (.close led)))

(defn write-diamond [led]
  (let [diamond [[0x00 0x00 0xFF 0xFE 0xFF 0xFF 0xFD 0x7F ] 
                 [0x00 0x02 0xFF 0xFB 0xBF 0xFF 0xF7 0xDF ] 
                 [0x00 0x04 0xFF 0xFB 0xBF 0xFF 0xFD 0x7F ] 
                 [0x00 0x06 0xFF 0xFE 0xFF]
                 ]]
    (dotimes [i 10]
      (doseq [row diamond]
        (write led (byte-array row) 8 0))
      (Thread/sleep 100))))
gary-rowe commented 8 years ago

Glad you managed to figure it out, and good to see a nice example of using the library with Clojure. Thank you for posting it.

I'm not sure why the scanning thread would cause SIGSEV crash, but I'll take a look and see if I can replicate it. Will be a good excuse for me to sharpen my Clojure skills...

mgerlach-klick commented 8 years ago

Thank you Gary, I appreciate you looking into it! Let me know if you'd like some help to get it set up as a Clojure project or if you'd like me to upload the whole thing somewhere!

gary-rowe commented 8 years ago

No worries. If you happen to have an example in Clojure that I could use as a launch pad that would be grand. I'm pretty flexible and I use Intellij 15 for development. Just pop something into github with a few basic instructions for a Java bod and I should be fine.

mgerlach-klick commented 8 years ago

Here you go: https://github.com/mgerlach-klick/cheekyled This includes the working implementation (core.clj), the crashing implementation (crash.clj) and some experiments with the purejavahidapi that you can ignore :) Just import the project into IntelliJ (presumably you will want to install the Cursive Clojure plugin, but I don't use IntelliJ and can't really tell you how to do that), run a REPL and evaluate the full crash.clj file. Then, in the repl (make sure you're in the in the cheekyled.crash namespace), evaluate (hid-services). After pretty exactly 30 seconds it'll crash. Let me know how it goes and thank you!

gary-rowe commented 8 years ago

OK. Thanks - that's really helpful. It's a bit late here (UK time) so I'll probably get started on it tomorrow.

tresf commented 8 years ago

For those still suffering this bug, calling shutdown() on the HidManager.getHidServices() object after you're done listing the devices (e.g. sometime soon after services.getAttachedHidDevices()) on Mac seems to prevent the random crashes.

Side note... There's still a second (seemly unrelated) crash that seems to occur randomly when the Java application closes, but it's too intermittent to provide steps for at this point and it's relatively benign as the by then the application had been used properly and a crash report will only popup up on close.

tresf commented 7 years ago

Update... We're running several hours stable now after the following changes:

Intermittent crashes

Releasing device crash

More

gary-rowe commented 7 years ago

I'll see if I can include those changes into the bundled libraries for 0.6.0.

tresf commented 3 years ago

@gary-rowe I'm working with my team to bump hid4java and was wondering if you had a list of patches that you apply on top of hidapi before a release so we know whether or not to ship our own hidapi with the above patch?

gary-rowe commented 3 years ago

Apologies for the slow response. I don't do anything special to hidapi before compilation - it's straight from the master branch of libusb/hidapi.

tresf commented 3 years ago

@gary-rowe gotcha, thanks.

Releasing device crash

  • Remove this line: hid.c#L1025, recompile on a suitable Mac build environment, re-bundle.

Since upstream has changed considerably, I'll retest. The line mentioned isn't changed, but I also don't see @mrpippy's patches, so if it continues with the latest, I'll open a new bug report and track accordingly.

lite1979 commented 3 years ago

Streaming on MacOS has been consistent both after suspend and without suspend/hibernate for over 72 hours :)

Edit: This is with hid4java-0.7.0.jar

gary-rowe commented 3 years ago

Good to know. Thanks for revisiting this one, @tresf.