Segmentation Fault on macOS 10.13.2 at start when enumerating hardware wallets

[tsutsu]

macOS version is 10.13.2 with Supplemental Update (17C205), running on Hackintosh hardware.

Tested on source-build Parity/v1.10.0-unstable-f044b61f4-20180111/x86_64-macos/rustc1.23.0.

Behavior replicates as well with nightly macOS release, and all variant releases from homebrew-paritytech.

Crash occurs before synchronization can begin.

Crash occurs regardless of network selected. (Tested all possible.)

Crash occurs repeatably every time parity is started.

Crash looks like this:

$ ./target/debug/parity
Loading config file from /Users/tsutsu/Library/Application Support/io.parity.ethereum/config.toml
2018-01-11 16:19:25  Starting Parity/v1.10.0-unstable-f044b61f4-20180111/x86_64-macos/rustc1.23.0
2018-01-11 16:19:25  Keys path /Volumes/Media/Blockchains/eth-ropsten/keys/Ropsten
2018-01-11 16:19:25  DB path /Volumes/Media/Blockchains/eth-ropsten/chains/test/db/ae90623718e47d66
2018-01-11 16:19:25  Path to dapps /Volumes/Media/Blockchains/eth-ropsten/dapps
2018-01-11 16:19:25  State DB configuration: fast
2018-01-11 16:19:25  Operating mode: passive
Segmentation fault: 11

rust-lldb reveals the following backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff29d6a328 CoreFoundation`CFSetGetCount + 24
    frame #1: 0x0000000103993865 parity`hid_enumerate(vendor_id=0, product_id=0) at hid.c:412
    frame #2: 0x000000010398aa8d parity`hidapi::{{impl}}::get_hid_device_info_vector at lib.rs:107
    frame #3: 0x000000010398a9b5 parity`hidapi::{{impl}}::new at lib.rs:91
    frame #4: 0x00000001037ab0c7 parity`hardware_wallet::{{impl}}::new at lib.rs:175
    frame #5: 0x0000000102533b8f parity`ethcore::account_provider::{{impl}}::new(sstore=Box<SecretStore> {

This looks like a problem in parity's fork of the hidapi-rs crate. Issues are closed there, so I'm opening one here instead.

As this issue hasn't been reported by any other macOS user, I'm guessing that this is caused by something weird and Hackintosh-related sitting in my device tree. Still a problem that might be encountered mysteriously by anyone else with such a configuration, though, so it'd be nice to get it fixed.

This PR in hidapi looks related to this problem.

Workarounds

Passing --no-hardware-wallets or setting disable_hardware = true in config.toml skips the broken part of the code, and parity starts successfully.

However, a segmentation fault still occurs on SIGINT:

^C2018-01-11 16:52:34  Finishing work, please wait...
Segmentation fault: 11

Potential solutions

• urge @signal11 to merge the above PR, and then update the hidapi submodule reference in your hidapi-rs fork.
• more drastically, fork hidapi itself, merge the PR above into your fork, and then update the hidapi submodule in your fork of hidapi-rs with your newly-forked hidapi.
• come up with some check equivalent to the one in the PR that could be done in hidapi-rs itself, and add it to your fork.

[debris]

Thanks @tsutsu for the detailed report! The PR in hidapi repo should solve the issue. Let's wait a couple of days and if it is not merged, let's fork hidapi

[niklasad1]

@tsutsu @debris
Is this solved?

[debris]

afaik no. this bug originates from hidapi and pr which fixes it is still pending -> signal11/hidapi#359