Segmentation fault on OSX when debugger in use by openocd about edbg

[JayToltTech]

Was going to uninstall hidapi from brew in case that was coming down as an Intel binary, but I noticed that open-ocd has this same dependency and it's working fine from my M1 Macbook, so the problem doesn't seem to be with hidapi being the wrong binary.

[ataradov]

I have no way of debugging this. If you feel like it, you can put print statements along the way to see where it fails specifically. May be we can figure out something based on this information. But otherwise there is nothing I can do.

[JayToltTech]

Thank you for the amazingly prompt response. Went in to start doing this and...was working fine.

Uh, "have you tried turning it off and turning it back on again?" All I can figure is a reboot whacked things in just the right way.

[JayToltTech]

Hmm, started to reproduce again. Using print statements, I've sussed out that dbg_open is failing the if (!handle) check and then when perror_exit calls into disconnect_debugger -> dap_led -> dbg_dap_cmd -> hid_write that's what triggers seg_fault, I assume because handle was never set and so hid_write is going boink.

[JayToltTech]

OK, root cause. If I'm simultaneously running openocd, then the device is busy and the dbg_open call fails, and as part of its failure path it tries writing to the invalid hid handle and segfaults.

edbg --list works and edbg -t list works while openocd has the device open, but edbg -t %device% fails, so to a noob like me it's a little mysterious.

[ataradov]

Should be fixed now. All those errors appeared after I tried to be nice and close the connection correctly.

Ideally individual OS drivers would track this and not execute commands if debugger is not open, but for not a global flag would do.

[JayToltTech]

Confirmed that I now receive "unable to open device: No such file or directory" when I reproduce the 'device in use by openocd' error condition.

Thank you.