Bump libusb to fix Windows segfault

[brandondahler]

Problem

When using iceprog.exe from the oss-cad-suite-windows-x64-20250506.exe release asset on a Windows 11 Professional machine at version 10.0.26100 Build 26100, I was unable to successfully program my board despite having correctly configured the driver to use libusbK (v3.1.0.0).

Instead of printing any error message, it would show the following output:

C:\....> iceprog_new.exe rgb_blink.bin
init..

Echoing the %ERRORLEVEL% return code gave me a value of -1073741819 which is C000 0005, the standard code for an access violation.

Solution

Bumped the libusb dependency from v1.0.24 to v1.0.28. This specifically incorporates a change in libusb made in 1.0.25 which states "Windows: Fix segfault with libusbk driver".

Debugging Performed

I found the following in the event log while debugging the issue.

Faulting application name: iceprog_old.exe, version: 0.0.0.0, time stamp: 0x67eca43a
Faulting module name: ntdll.dll, version: 10.0.26100.3775, time stamp: 0x5e4be250
Exception code: 0xc0000005
Fault offset: 0x00000000000108fd
Faulting process id: 0x6DD4
Faulting application start time: 0x1DBBFC7FDE8A6AF
Faulting application path: C:\oss-cad-suite\bin\iceprog_old.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: a006eedc-5bab-4256-a7c7-7f7d46f81692
Faulting package full name: 
Faulting package-relative application ID: 

Building the iceprog code from in MSYS2 with the mingw-w64-ucrt-x86_64 toolchain proved successful; however, dropping that newly compiled version into my oss-cad-suite installation continued to fail. Copying over the libftdi1.dll did not yield success; however, copying over the libusb-1.0.dll from my MSYS2 environment to the oss-cad-suite install caused the existing iceprog.exe in the oss-cad-suite code to work again.

Inspecting the version that was copied from my MYSY2 install, I found that it was using a newer version (1.0.27 vs 1.0.24 as in the current code).

[mmicko]

Thanks for contribution, but unfortunately this is not going to work. Reason is that libusb repo is only used to create a small utility (lsusb) but not for creating libusb library and using it from other tools.
Since docker container based on Fedora is used with cross compilation environment and libraries for mingw, only option would be here to update base image to latest (also need to confirm that they package proper libusb version), and that usually breaks lot of things and takes a while to test (since full rebuild of all packages needs to be done), so please be patient before this is done.

[brandondahler]

No problem, I'll close this out and open an issue later today or try to do the upgrade and test it out locally. It looks like Fedora 39, 40, and 41 packages patched versions of 1.0.24 (per http://fedora.mirror.constant.com/fedora/linux/releases/39/Everything/x86_64/os/Packages/m/), but 42 packages 1.0.28.