segmentation fault - EXC_BAD_ACCESS (code=1, address=0x714)

[noppej]

The following happens in releases 0.7 and 0.8 of rusb, but NOT in 0.6 (I am running MacOS Catalina 10.15.7) with the latest released versions of VSCode, MacOS dev tools, and Rust)

It shows up in code (for example probe-rs/probe-rs/cli ) and can be reproduced without any USB devices attached, by running probe-rs-cli list, after doing a cargo install probe-rs-cli

This is my call stack at the point of failure. Let me know if you need additional information.

pthread_mutex_lock (@pthread_mutex_lock:3)
usbi_mutex_lock (/Users/Jack/.cargo/registry/src/github.com-1ecc6299db9ec823/libusb1-sys-0.5.0/libusb/libusb/os/threads_posix.h:46)
libusb_unref_device (/Users/Jack/.cargo/registry/src/github.com-1ecc6299db9ec823/libusb1-sys-0.5.0/libusb/libusb/core.c:1194)
libusb_unref_device (/Users/Jack/.cargo/registry/src/github.com-1ecc6299db9ec823/libusb1-sys-0.5.0/libusb/libusb/core.c:1201)
process_new_device (/Users/Jack/dev/probe-rs/target/debug/build/libusb1-sys-29e9c85c70119d88/out/source/libusb-1.0.22/libusb/os/darwin_usb.c:1063)
darwin_scan_devices (/Users/Jack/dev/probe-rs/target/debug/build/libusb1-sys-29e9c85c70119d88/out/source/libusb-1.0.22/libusb/os/darwin_usb.c:1079)
darwin_init (/Users/Jack/dev/probe-rs/target/debug/build/libusb1-sys-29e9c85c70119d88/out/source/libusb-1.0.22/libusb/os/darwin_usb.c:543)
libusb_init (/Users/Jack/.cargo/registry/src/github.com-1ecc6299db9ec823/libusb1-sys-0.5.0/libusb/libusb/core.c:2316)
new (/Users/Jack/.cargo/registry/src/github.com-1ecc6299db9ec823/rusb-0.8.0/src/context.rs:209)
list_daplink_devices (/Users/Jack/dev/probe-rs/probe-rs/src/probe/daplink/tools.rs:15)
list_all (/Users/Jack/dev/probe-rs/probe-rs/src/probe/mod.rs:194)
list_connected_devices (/Users/Jack/dev/probe-rs/cli/src/main.rs:135)
main (/Users/Jack/dev/probe-rs/cli/src/main.rs:124)
call_once<fn() -> core::result::Result<(), anyhow::Error>,()> (/Users/Jack/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/ops/function.rs:227)
__rust_begin_short_backtrace<fn() -> core::result::Result<(), anyhow::Error>,core::result::Result<(), anyhow::Error>> (/Users/Jack/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:125)
{{closure}}<core::result::Result<(), anyhow::Error>> (/Users/Jack/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:66)
core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once (@std::rt::lang_start_internal::h1faf79574185df6d:159)
std::panicking::try::do_call (@std::rt::lang_start_internal::h1faf79574185df6d:157)
std::panicking::try (@std::rt::lang_start_internal::h1faf79574185df6d:157)
std::panic::catch_unwind (@std::rt::lang_start_internal::h1faf79574185df6d:157)
lang_start_internal (@std::rt::lang_start_internal::h1faf79574185df6d:157)
lang_start<core::result::Result<(), anyhow::Error>> (/Users/Jack/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:65)
main (@main:12)
start (@start:4)

[a1ien]

Can you compile and run libusb example https://github.com/libusb/libusb/blob/master/examples/listdevs.c . I think it's related to libusb nor rust wrapper

[noppej]

Hmmm ... I think you might be onto something, and I think it is related to my OS version. I can build it in XCode, but when i try to run it with Xcode, I get ...

Details

JackiMac cannot run dpfp_threaded.
Domain: IDEFoundationErrorDomain
Code: 3
Recovery Suggestion: JackiMac runs macOS 10.15.7, which is lower than dpfp_threaded’s minimum deployment target of 11.1. Change your project’s minimum deployment target or upgrade JackiMac’s version of macOS.
--

System Information

macOS Version 10.15.7 (Build 19H524)
Xcode 12.4 (17801) (Build 12D4e)
Timestamp: 2021-02-27T11:40:43-05:00

Is that relevant?

Can you compile and run libusb example https://github.com/libusb/libusb/blob/master/examples/listdevs.c . I think it's related to libusb nor rust wrapper

[Yatekii]

Hmm is there a reason you are not on Big Sur yet? At least the error seems to indicate that you need BigSur :)

[noppej]

Haha ... yeah, I need new hardware. I was being stubborn because my Mac's performance is still very good, but due to the hardware age, I can't upgrade past my current version. If it is confirmed that this is the root cause, then I'm happy to close this issue.

[Yatekii]

This happens on Big Sur too :/

[noppej]

Good to know. Thanks for testing. I will continue working against rusb 0.6.0 and hopefully @a1ien will have some insight to help us along to the next step.

[a1ien]

If problem happens with example from libusb than you must open issues in https://github.com/libusb/libusb 0.7 version of rusb diff from 0.6 that in 0.7 has an updated version of libusb to 1.0.24 You can try also run libusb 1.0.23 And with macOs i can't help nothing.

[noppej]

@a1ien Thank you for the guidance. I've reported it as https://github.com/libusb/libusb/issues/881

[mcuee]

From libusb ticket. I know nothing about Rust but anyway I just installed rust using Homebrew and probe-rs-cli and nothing wrong here under my Mac Mini M1.

mcuee@mcuees-Mac-mini ~ % echo $PATH
/Users/mcuee/.cargo/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin
mcuee@mcuees-Mac-mini ~ % probe-rs-cli list
No devices were found.

mcuee@mcuees-Mac-mini rusb % sw_vers
ProductName:    macOS
ProductVersion: 11.2.2
BuildVersion:   20D80

mcuee@mcuees-Mac-mini rusb % cargo --version
cargo 1.49.0

mcuee@mcuees-Mac-mini rusb % cargo run --release --example libusb_info         
   Compiling pkg-config v0.3.19
   Compiling cc v1.0.67
   Compiling libc v0.2.87
   Compiling memchr v2.3.4
   Compiling once_cell v1.7.2
   Compiling rusb v0.8.0 (/Users/mcuee/build/libusb/examples/rusb)
   Compiling regex-syntax v0.6.22
   Compiling thread_local v1.1.3
   Compiling libusb1-sys v0.5.0
   Compiling aho-corasick v0.7.15
   Compiling regex v1.4.3
    Finished release [optimized] target(s) in 6.59s
     Running `target/release/examples/libusb_info`
libusb v1.0.24.11584
has capability? true
has hotplug? true
has HID access? false
supports detach kernel driver? false

[mcuee]

Please post the libusb debug log in the libusb ticket https://github.com/libusb/libusb/issues/881, if you can compile and run any of the libusb examples in the libusb tree and then cause the crash.

Eg: https://github.com/libusb/libusb/blob/master/examples/listdevs.c

https://github.com/libusb/libusb/blob/master/examples/xusb.c

[svenstucki]

I did some experiments with my 2020 Intel MBP. The rusb and libusb examples run fine, however I do get a segfault in probe-rs-cli.

Here's my output:

$ cargo run --release --example libusb_info
   Compiling rusb v0.8.0 (/Users/sven/git/other/rusb)
    Finished release [optimized] target(s) in 28.53s
     Running `target/release/examples/libusb_info`
libusb v1.0.24.11584
has capability? true
has hotplug? true
has HID access? false
supports detach kernel driver? false

$ cargo run --release --example list_devices
   Compiling rusb v0.8.0 (/Users/sven/git/other/rusb)
    Finished release [optimized] target(s) in 1.09s
     Running `target/release/examples/list_devices`
Bus 020 Device 031 ID 0d28:0204   12 Mbps
Device Descriptor:
  bcdUSB              2.10
...

$ sw_vers
ProductName:    macOS
ProductVersion: 11.1
BuildVersion:   20C69

$ git log
commit f611e84804723c73c6b6993c73b5bfa2c44ab025 (HEAD -> master, origin/master, origin/HEAD)

---

What happens in probe-rs-cli (rev 9ae0e98ebbb00a612eff3930d78b4d40a2d2908c) is the following:

$ cargo run -p probe-rs-cli -- list
    Finished dev [unoptimized + debuginfo] target(s) in 0.95s
     Running `target/debug/probe-rs-cli list`
[1]    72059 segmentation fault  cargo run -p probe-rs-cli -- list

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x314)
  * frame #0: 0x00007fff20387d9b libsystem_pthread.dylib`pthread_mutex_lock + 4
    frame #1: 0x00000001006d9ca5 probe-rs-cli`usbi_mutex_lock(mutex=0x0000000000000314) at threads_posix.h:46:2
    frame #2: 0x00000001006da3b5 probe-rs-cli`libusb_unref_device(dev=0x0000000000000314) at core.c:1194:2
    frame #3: 0x00000001006da415 probe-rs-cli`libusb_unref_device(dev=0x0000000101b09570) at core.c:1201:3
    frame #4: 0x00000001006cd9f2 probe-rs-cli`process_new_device(ctx=0x0000000103200000, service=3619) at darwin_usb.c:1063:5
    frame #5: 0x00000001006cd249 probe-rs-cli`darwin_scan_devices(ctx=0x0000000103200000) at darwin_usb.c:1079:12
    frame #6: 0x00000001006cb791 probe-rs-cli`darwin_init(ctx=0x0000000103200000) at darwin_usb.c:543:8
    frame #7: 0x00000001006db1f7 probe-rs-cli`libusb_init(context=0x00007ffeefbfedc0) at core.c:2316:7
    frame #8: 0x00000001006d7128 probe-rs-cli`rusb::context::Context::new::h120a7124c1f7f45d at context.rs:209:21
    frame #9: 0x00000001004ac321 probe-rs-cli`probe_rs::probe::daplink::tools::list_daplink_devices::hf6b7d37342d38074 at tools.rs:15:11
    frame #10: 0x00000001004bc328 probe-rs-cli`probe_rs::probe::Probe::list_all::hc3f5dce9e21c9368 at mod.rs:194:24
    frame #11: 0x0000000100033567 probe-rs-cli`probe_rs_cli::list_connected_devices::h2ab9f881622be2a3 at main.rs:135:17
    frame #12: 0x0000000100033087 probe-rs-cli`probe_rs_cli::main::he54d9b29cc6dc2f2 at main.rs:124:25
    frame #13: 0x0000000100004a1e probe-rs-cli`core::ops::function::FnOnce::call_once::h6a0ffe48bef2be7d((null)=(probe-rs-cli`probe_rs_cli::main::he54d9b29cc6dc2f2 at main.rs:117), (null)=<unavailable>) at function.rs:227:5
    frame #14: 0x0000000100007841 probe-rs-cli`std::sys_common::backtrace::__rust_begin_short_backtrace::hd2b8332c9d3041ba(f=(probe-rs-cli`probe_rs_cli::main::he54d9b29cc6dc2f2 at main.rs:117)) at backtrace.rs:125:18
    frame #15: 0x0000000100008bb4 probe-rs-cli`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hd783db9d115c69f7 at rt.rs:66:18
    frame #16: 0x00000001007ad684 probe-rs-cli`std::rt::lang_start_internal::h6cd9161d564e26bc [inlined] core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::h0e4751aa18b978d3 at function.rs:259:13 [opt]
    frame #17: 0x00000001007ad67d probe-rs-cli`std::rt::lang_start_internal::h6cd9161d564e26bc [inlined] std::panicking::try::do_call::h8811e2313bc8a6c8 at panicking.rs:379 [opt]
    frame #18: 0x00000001007ad67d probe-rs-cli`std::rt::lang_start_internal::h6cd9161d564e26bc [inlined] std::panicking::try::h262921847276e698 at panicking.rs:343 [opt]
    frame #19: 0x00000001007ad67d probe-rs-cli`std::rt::lang_start_internal::h6cd9161d564e26bc [inlined] std::panic::catch_unwind::h226fd0bf19dc973f at panic.rs:431 [opt]
    frame #20: 0x00000001007ad67d probe-rs-cli`std::rt::lang_start_internal::h6cd9161d564e26bc at rt.rs:51 [opt]
    frame #21: 0x0000000100008b91 probe-rs-cli`std::rt::lang_start::h7f69c9fdffea0b1f(main=(probe-rs-cli`probe_rs_cli::main::he54d9b29cc6dc2f2 at main.rs:117), argc=2, argv=0x00007ffeefbff4e8) at rt.rs:65:5
    frame #22: 0x00000001000362c2 probe-rs-cli`main + 34
    frame #23: 0x00007fff203a7621 libdyld.dylib`start + 1
    frame #24: 0x00007fff203a7621 libdyld.dylib`start + 1

Definitely looks like the same issue as @noppej - just not sure which library is responsible for it.

[a1ien]

Can you replace in list_devices.rs from

    for device in DeviceList::new()?.iter() {

to

    for device in rusb::Context::new().and_then(|ctx| ctx.devices())?.iter() {

Since its only one difference probe-rs vs example. In example used GlobalContext but probe-rs use local context

[svenstucki]

This also worked for me, it properly lists the devices.

[a1ien]

@noppej what about you? Also try change probe-rs/src/probe/daplink/tools.rs

    match rusb::Context::new().and_then(|ctx| ctx.devices()) {

to

match rusb::DeviceList::new() {

and get_daplink_info(device: &Device<rusb::Context>) to get_daplink_info(device: &Device<impl rusb::UsbContext>)

Also to be sure that libusb build from source change rusb = "0.7.0" to rusb = { version = "0.7.0", features = ["vendored"] }

[noppej]

@a1ien I made the changes you suggested, but still get a segmentation fault. Am I also supposed to make the changes in list_devices.rs that you mention higher up?

[svenstucki]

I'm getting a compile error with your code - sorry, I'm rather new to rust. Will have a deeper look later with @Yatekii and do some debugging.

However, what I noticed is, that the segfault happens before get_daplink_info gets called. Just calling devices.iter() alone does not trigger it for me though.

Thanks for your help, will hopefully get back with more info soon.

[noppej]

@a1ien ... I did notice something else while building prober-rs/cli ... rusb showed up being compiled twice. Once for 0.7 and then again later for 0.6.3.

A cargo tree showed me this ... jaylink buids 0.6.3. Is this expected and OK, or?

 cargo tree
probe-rs-cli v0.10.0 (/Users/Jack/dev/probe-rs/cli)
├── anyhow v1.0.38
├── bitfield v0.13.2
├── capstone v0.7.0
│   ├── capstone-sys v0.11.0
│   │   └── libc v0.2.86
│   │   [build-dependencies]
│   │   └── cc v1.0.67
│   └── libc v0.2.86
├── colored v2.0.0
│   ├── atty v0.2.14
│   │   └── libc v0.2.86
│   └── lazy_static v1.4.0
├── ihex v3.0.0
├── jep106 v0.2.5
│   └── serde v1.0.123
│       └── serde_derive v1.0.123 (proc-macro)
│           ├── proc-macro2 v1.0.24
│           │   └── unicode-xid v0.2.1
│           ├── quote v1.0.9
│           │   └── proc-macro2 v1.0.24 (*)
│           └── syn v1.0.60
│               ├── proc-macro2 v1.0.24 (*)
│               ├── quote v1.0.9 (*)
│               └── unicode-xid v0.2.1
├── log v0.4.14
│   └── cfg-if v1.0.0
├── num-traits v0.2.14
│   [build-dependencies]
│   └── autocfg v1.0.1
├── parse_int v0.5.0
│   └── num-traits v0.2.14 (*)
├── pretty_env_logger v0.4.0
│   ├── env_logger v0.7.1
│   │   ├── atty v0.2.14 (*)
│   │   ├── humantime v1.3.0
│   │   │   └── quick-error v1.2.3
│   │   ├── log v0.4.14 (*)
│   │   ├── regex v1.4.3
│   │   │   ├── aho-corasick v0.7.15
│   │   │   │   └── memchr v2.3.4
│   │   │   ├── memchr v2.3.4
│   │   │   ├── regex-syntax v0.6.22
│   │   │   └── thread_local v1.1.3
│   │   │       └── once_cell v1.7.0
│   │   └── termcolor v1.1.2
│   └── log v0.4.14 (*)
├── probe-rs v0.10.1 (/Users/Jack/dev/probe-rs/probe-rs)
│   ├── anyhow v1.0.38
│   ├── base64 v0.13.0
│   ├── bitfield v0.13.2
│   ├── enum-primitive-derive v0.2.1 (proc-macro)
│   │   ├── num-traits v0.2.14 (*)
│   │   ├── quote v1.0.9 (*)
│   │   └── syn v1.0.60 (*)
│   ├── funty v1.1.0
│   ├── gimli v0.23.0
│   │   ├── fallible-iterator v0.2.0
│   │   ├── indexmap v1.6.1
│   │   │   └── hashbrown v0.9.1
│   │   │   [build-dependencies]
│   │   │   └── autocfg v1.0.1
│   │   └── stable_deref_trait v1.2.0
│   ├── hidapi v1.2.5
│   │   └── libc v0.2.86
│   │   [build-dependencies]
│   │   ├── cc v1.0.67
│   │   └── pkg-config v0.3.19
│   ├── ihex v3.0.0
│   ├── jaylink v0.1.5
│   │   ├── bitflags v1.2.1
│   │   ├── byteorder v1.4.2
│   │   ├── log v0.4.14 (*)
│   │   └── rusb v0.6.3
│   │       ├── libc v0.2.86
│   │       └── libusb1-sys v0.3.6
│   │           └── libc v0.2.86
│   │           [build-dependencies]
│   │           ├── cc v1.0.67
│   │           ├── libflate v0.1.27
│   │           │   ├── adler32 v1.2.0
│   │           │   ├── crc32fast v1.2.1
│   │           │   │   └── cfg-if v1.0.0
│   │           │   ├── rle-decode-fast v1.0.1
│   │           │   └── take_mut v0.2.2
│   │           ├── pkg-config v0.3.19
│   │           └── tar v0.4.33
│   │               ├── filetime v0.2.14
│   │               │   ├── cfg-if v1.0.0
│   │               │   └── libc v0.2.86
│   │               ├── libc v0.2.86
│   │               └── xattr v0.2.2
│   │                   └── libc v0.2.86
│   ├── jep106 v0.2.5 (*)
│   ├── lazy_static v1.4.0
│   ├── log v0.4.14 (*)
│   ├── num-traits v0.2.14 (*)
│   ├── object v0.23.0
│   │   ├── flate2 v1.0.20
│   │   │   ├── cfg-if v1.0.0
│   │   │   ├── crc32fast v1.2.1 (*)
│   │   │   ├── libc v0.2.86
│   │   │   └── miniz_oxide v0.4.4
│   │   │       └── adler v1.0.2
│   │   │       [build-dependencies]
│   │   │       └── autocfg v1.0.1
│   │   └── wasmparser v0.57.0
│   ├── rusb v0.7.0
│   │   ├── libc v0.2.86
│   │   └── libusb1-sys v0.5.0
│   │       └── libc v0.2.86
│   │       [build-dependencies]
│   │       ├── cc v1.0.67
│   │       └── pkg-config v0.3.19
│   ├── scroll v0.10.2
│   ├── serde v1.0.123 (*)
│   ├── serde_yaml v0.8.17
│   │   ├── dtoa v0.4.7
│   │   ├── linked-hash-map v0.5.4
│   │   ├── serde v1.0.123 (*)
│   │   └── yaml-rust v0.4.5
│   │       └── linked-hash-map v0.5.4
│   ├── static_assertions v1.1.0
│   ├── svg v0.9.0
│   └── thiserror v1.0.24
│       └── thiserror-impl v1.0.24 (proc-macro)
│           ├── proc-macro2 v1.0.24 (*)
│           ├── quote v1.0.9 (*)
│           └── syn v1.0.60 (*)
│   [build-dependencies]
│   └── probe-rs-t2rust v0.7.0 (/Users/Jack/dev/probe-rs/probe-rs-t2rust)
│       ├── base64 v0.13.0
│       ├── proc-macro2 v1.0.24 (*)
│       ├── quote v1.0.9 (*)
│       ├── scroll v0.10.2
│       └── serde_yaml v0.8.17 (*)
├── ron v0.6.4
│   ├── base64 v0.13.0
│   ├── bitflags v1.2.1
│   └── serde v1.0.123 (*)
├── rustyline v7.1.0
│   ├── bitflags v1.2.1
│   ├── cfg-if v1.0.0
│   ├── dirs-next v2.0.0
│   │   ├── cfg-if v1.0.0
│   │   └── dirs-sys-next v0.1.2
│   │       └── libc v0.2.86
│   ├── fs2 v0.4.3
│   │   └── libc v0.2.86
│   ├── libc v0.2.86
│   ├── log v0.4.14 (*)
│   ├── memchr v2.3.4
│   ├── nix v0.19.1
│   │   ├── bitflags v1.2.1
│   │   ├── cfg-if v1.0.0
│   │   └── libc v0.2.86
│   ├── unicode-segmentation v1.7.1
│   ├── unicode-width v0.1.8
│   └── utf8parse v0.2.0
├── scroll v0.10.2
├── structopt v0.3.21
│   ├── clap v2.33.3
│   │   ├── ansi_term v0.11.0
│   │   ├── atty v0.2.14 (*)
│   │   ├── bitflags v1.2.1
│   │   ├── strsim v0.8.0
│   │   ├── textwrap v0.11.0
│   │   │   └── unicode-width v0.1.8
│   │   ├── unicode-width v0.1.8
│   │   └── vec_map v0.8.2
│   ├── lazy_static v1.4.0
│   └── structopt-derive v0.4.14 (proc-macro)
│       ├── heck v0.3.2
│       │   └── unicode-segmentation v1.7.1
│       ├── proc-macro-error v1.0.4
│       │   ├── proc-macro-error-attr v1.0.4 (proc-macro)
│       │   │   ├── proc-macro2 v1.0.24 (*)
│       │   │   └── quote v1.0.9 (*)
│       │   │   [build-dependencies]
│       │   │   └── version_check v0.9.2
│       │   ├── proc-macro2 v1.0.24 (*)
│       │   ├── quote v1.0.9 (*)
│       │   └── syn v1.0.60 (*)
│       │   [build-dependencies]
│       │   └── version_check v0.9.2
│       ├── proc-macro2 v1.0.24 (*)
│       ├── quote v1.0.9 (*)
│       └── syn v1.0.60 (*)
└── thiserror v1.0.24 (*)

[a1ien]

A cargo tree showed me this ... jaylink buids 0.6.3. Is this expected and OK, or?

No. It's may be root of problem. You cant try install libusb global. I don't know much about macos, but try

brew install pkg-config
brew install libusb
# check that libusb install
pkg-config --libs --cflags libusb-1.0

now if you build rusb and other libs must be used system version of libusb and not try to build vendored

P.S. rusb 0.6 have libusb 1.0.23 vendored and rusb >= 0.7 have libusb 1.0.24 vendored. That may be problem

[svenstucki]

Yes, that was also our conclusion.

When adding jaylink = "0.1.5" to the rusb Cargo.toml and the following to the end of main, the segfault appears:

    use jaylink;
    jaylink::scan_usb();

[svenstucki]

When upgrading to current master of jaylink, the problem no longer occurs in probe-rs...

[kevinmehall]

The latest libusb1-sys has links in Cargo.toml that should prevent multiple versions from being linked, but that wasn't there in v0.3.6.

[mcuee]

FYI, I have J-Link as well (old IAR OEM J-Link) and here it is.

mcuee@mcuees-Mac-mini ~ % probe-rs-cli list
The following devices were found:
[0]: J-Link (J-Link) (VID: 1366, PID: 0101, Serial: 123456, JLink)

mcuee@mcuees-Mac-mini probe-rs % cargo tree 

    ├── jaylink v0.1.5
    │   ├── bitflags v1.2.1
    │   ├── byteorder v1.4.2
    │   ├── log v0.4.14 (*)
    │   └── rusb v0.6.3
    │       ├── libc v0.2.87
    │       └── libusb1-sys v0.3.6
    │           └── libc v0.2.87
    │           [build-dependencies]
    │           ├── cc v1.0.67
    │           ├── libflate v0.1.27
    │           │   ├── adler32 v1.2.0
    │           │   ├── crc32fast v1.2.1
    │           │   │   └── cfg-if v1.0.0
    │           │   ├── rle-decode-fast v1.0.1
    │           │   └── take_mut v0.2.2
    │           ├── pkg-config v0.3.19
    │           └── tar v0.4.33
    │               ├── filetime v0.2.14
    │               │   ├── cfg-if v1.0.0
    │               │   └── libc v0.2.87
    │               ├── libc v0.2.87
    │               └── xattr v0.2.2
    │                   └── libc v0.2.87

    ├── rusb v0.7.0
    │   ├── libc v0.2.87
    │   └── libusb1-sys v0.5.0
    │       └── libc v0.2.87
    │       [build-dependencies]
    │       ├── cc v1.0.67
    │       └── pkg-config v0.3.19

[Yatekii]

Yeah could be an edge case. It works on Linux too. Just Intel Macs seem to be prone to it.

[mcuee]

Probably there are different issues here. @noppej your issue may be related to a mis configuration which has two rusb version and different libusb version mixed. Or maybe related to daplink. Seems that Stlink is okay. https://github.com/probe-rs/probe-rs/issues/558

@svenstucki your issue seems to be related to libjaylink, since you say 0.1.5 causes problem but not latest git.

There are different versions of J-Link devices and last time (many years ago) it took the openocd project quite sometime to get it sorted out. But libjaylink seems to be pretty good based on my limited testing of openocd.

[mcuee]

To know the low-level libusb debug info, run your program with LIBUSB_DEBUG=4 set, then from the debug log, you can see the low level libusb function which failed. Then it is easier to see if it is a problem with libusb or rusb or probe-rs.

[mcuee]

Please also take a look at the following libusb issues.

1) Segfault at libusb_exit() -- libusb crashing on the wrong context. This could be the issues here. It is expected behavior but there is an improvement already (not yet merged but should be soon). https://github.com/libusb/libusb/issues/855

2) libusb_set_interface_alt_setting returns kIOUSBPipeStalled on macOS (fixed in latest git) https://github.com/libusb/libusb/issues/838

[svenstucki]

Hey @mcuee it should be the same problem.

jaylink = "0.1.5" pulls in rusb 0.6.2, which uses libusb1-sys 0.3.5. So when I add it to the rusb master, it produces the clash with the versions, as rusb currently uses libusb1-sys 0.5.0. The current master of jaylink uses rusb 0.8.0 which resolves the conflict.

[Yatekii]

@mcuee it is 100% the clashing dependencies.

• It is not libjaylink (the C library) but the Rust crate called jaylink.
• It does not matter if a J-Link is connected or not. We never even scan for J-Link devices. It crashes when scanning general USB devices with libusb already. Having the dependency alone linked suffices to crash it.

It really is just the incompatible interfaces. Which means libusb violates Semver :)

Thanks for investigating :) We know the fix now, which is first downgrading to rusb 0.6.0 and when jaylink upgrades to 0.8.0 we'll upgrade too.

[mcuee]

Thanks the clarification. Good to know that it is the clashing dependencies issue.

[mcuee]

https://github.com/libusb/libusb/issues/892

@mcuee it is 100% the clashing dependencies.

• It is not libjaylink (the C library) but the Rust crate called jaylink.
• It does not matter if a J-Link is connected or not. We never even scan for J-Link devices. It crashes when scanning general USB devices with libusb already. Having the dependency alone linked suffices to crash it.

It really is just the incompatible interfaces. Which means libusb violates Semver :)

Thanks for investigating :) We know the fix now, which is first downgrading to rusb 0.6.0 and when jaylink upgrades to 0.8.0 we'll upgrade too.