Run tests for AppVeyor too #1360

RReverser · 2023-12-05T04:06:32Z

Follow-up to #1349.

RReverser · 2023-12-05T04:12:59Z

@tormodvolden FWIW this won't reproduce on CI since it doesn't have cross-platform emulated devices yet, but this revealed that the new extra checks in stress_mt are actually failing for me on Windows:

Running multithreaded init/exit test...
Starting 8 threads
Running multithreaded init/exit test with enumeration...
Starting 8 threads
Thread 1: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 2: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 3: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 5: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 7: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 0: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 0 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 1 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 2 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 3 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 6: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 4: device 0: mismatch in field bMaxPacketSize0: 64 != 8
Thread 4 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 5 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 6 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 7 failed (iteration 1): LIBUSB_ERROR_OTHER
All threads discovered 0 devices (0 not opened)
All done, 8 errors

Are there known limitation in regard to bMaxPacketSize0 not being reported correctly on Windows?

mcuee · 2023-12-05T04:16:26Z

@RReverser

What is the device caussing the failure under Windows? Maybe you can post the debug log using the example program (xusb -d vid:pid) fo that device. Thanks.

RReverser · 2023-12-05T04:17:46Z

Also, if I comment out bMaxPacketSize0 check, the next to fail is bcdDevice:

Starting 8 threads
Thread 2: device 0: mismatch in field bcdDevice: 256 != 20
Thread 7: device 0: mismatch in field bcdDevice: 256 != 20
Thread 5: device 0: mismatch in field bcdDevice: 256 != 20
Thread 0: device 0: mismatch in field bcdDevice: 256 != 20
Thread 0 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 3: device 0: mismatch in field bcdDevice: 256 != 20
Thread 4: device 0: mismatch in field bcdDevice: 256 != 20
Thread 1: device 0: mismatch in field bcdDevice: 256 != 20
Thread 1 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 2 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 3 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 4 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 5 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 6: device 0: mismatch in field bcdDevice: 256 != 20
Thread 6 failed (iteration 1): LIBUSB_ERROR_OTHER
Thread 7 failed (iteration 1): LIBUSB_ERROR_OTHER
All threads discovered 0 devices (0 not opened)

I'll try to investigate further.

RReverser · 2023-12-05T04:22:57Z

What is the device caussing the failure under Windows?

~~Hm it seems to be some generic HID USB device 1bcf:0005. It shows as disconnected in USBDeview, maybe that's why.~~

I don't want to post raw xusb logs since they seem to contain list of all connected devices.

RReverser · 2023-12-05T04:25:34Z

Nvm, I looked at the wrong device that shared same vid:pid.

It's actually my mouse:

mcuee · 2023-12-05T05:49:23Z

Test results on my Windows 11 laptop.

git master: no issue

PS C:\work\libusb\libusb\build\v143\x64\Debug> .\stress_mt.exe
Running multithreaded init/exit test...
Starting 8 threads
Running multithreaded init/exit test with enumeration...
Starting 8 threads
Thread 0 discovered 6 devices
Thread 1 discovered 6 devices
Thread 2 discovered 6 devices
Thread 3 discovered 6 devices
Thread 4 discovered 6 devices
Thread 5 discovered 6 devices
Thread 6 discovered 6 devices
Thread 7 discovered 6 devices
All done, 0 errors

This PR: failed

PS C:\work\libusb\libusb_pr1360\build\v143\x64\Debug> .\stress_mt.exe
Running multithreaded init/exit test...
Starting 8 threads
Running multithreaded init/exit test with enumeration...
Starting 8 threads
Thread 0 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 1 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 2 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 3 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 4 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 5 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 6 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
Thread 7 failed (iteration 1): LIBUSB_ERROR_NOT_SUPPORTED
All threads discovered 0 devices (0 not opened)
All done, 8 errors

Debug log comparison

$Env:LIBUSB_DEBUG=4
cd C:\work\libusb\libusb\build\v143\x64\Debug
.\stress_mt.exe >git_master.log 2>&1
cd C:\work\libusb\libusb_pr1360\build\v143\x64\Debug
.\stress_mt.exe >git_pr1360.log 2>&1

git_master.zip

git_pr1360.zip

mcuee · 2023-12-05T05:55:05Z

Also, if I comment out bMaxPacketSize0 check, the next to fail is bcdDevice:

I'll try to investigate further.

Hmm, I can not reproduce the issue with my HID devices. Maybe you want to run xusb -d 1bcf:005 and post the output.

PS C:\work\libusb\libusb_pr1360\build\v143\x64\Debug> .\listdevs.exe
libusb: info [winusbx_init] WinUSB DLL available (with isoch support)
libusb: info [windows_init] UsbDk backend is not available
8087:0026 (bus 1, device 2) path: 10
1ea7:0064 (bus 1, device 3) path: 3
04f2:b6dd (bus 1, device 4) path: 5
1c7a:0575 (bus 1, device 1) path: 7
8086:a0ed (bus 1, device 0)
8086:9a13 (bus 2, device 0)
PS C:\work\libusb\libusb_pr1360\build\v143\x64\Debug> .\testlibusb.exe
libusb: info [winusbx_init] WinUSB DLL available (with isoch support)
libusb: info [windows_init] UsbDk backend is not available
Dev (bus 1, device 2): 8087 - 0026 speed: 12M
Dev (bus 1, device 3): 1EA7 - 0064 speed: 12M
libusb: warning [hid_open] could not open HID device in R/W mode (keyboard or mouse?) - trying without
  Product:                   2.4G Mouse
Dev (bus 1, device 4): 04F2 - B6DD speed: 480M
Dev (bus 1, device 1): 1C7A - 0575 speed: 480M
libusb: error [winusbx_open] could not open device \\?\USB#VID_1C7A&PID_0575#077E2F9A#{A5DCBF10-6530-11D2-901F-00C04FB951ED} (interface 0): [5] Access is denied.
Dev (bus 1, device 0): 8086 - A0ED speed: 5G
Dev (bus 2, device 0): 8086 - 9A13 speed: 5G

RReverser · 2023-12-05T13:03:49Z

git master: no issue

That's because there was a bug in test where it would quietly continue after a error, see the change in stress_mt.c.

Previously the loop would continue even if error has already occured since `goto close` alone doesn't stop early. References #1360

tormodvolden · 2023-12-13T00:00:47Z

Cross-posting from #1372:
It seems some devices/drivers will report LIBUSB_ERROR_NOT_SUPPORTED on open. If we ignore them the same way as LIBUSB_ERROR_ACCESS, it looks better. However, I see some funny descriptor mismatches, like the Surface keyboard having mismatch on bcdUSB and bcdDevice. My WinUSB/libusbK devices pass the test.

EDIT: Looking at the mismatch reported above, it is also a HID device...

EDIT 2: Ah, _hid_get_device_descriptor() hardcodes bcdUSB, bcdDevice, and bMaxPacketSize0 ...

RReverser · 2023-12-13T00:26:32Z

EDIT 2: Ah, _hid_get_device_descriptor() hardcodes bcdUSB, bcdDevice, and bMaxPacketSize0 ...

Ah that would do it. Would it be fair to call this a bug then? (since it doesn't return real values)

Or is that a well-known limitation that is unlikely to go away?

RReverser · 2023-12-13T00:27:48Z

It seems some devices/drivers will report LIBUSB_ERROR_NOT_SUPPORTED on open. If we ignore them the same way as LIBUSB_ERROR_ACCESS

Is this different error code originating from drivers or from Windows backend of libusb itself? If it's the latter, it would be nice to fix it in the backend instead for consistency with other platforms / backends.

tormodvolden · 2023-12-13T00:39:53Z

Or is that a well-known limitation that is unlikely to go away?

I don't know enough about HID to tell if it is possibly to get these values correctly.

RReverser · 2023-12-13T00:43:36Z

I don't know enough about HID to tell if it is possibly to get these values correctly.

Worst-case, it should be possible to get them via control transfer like the test does?

tormodvolden · 2023-12-13T00:57:36Z

Worst-case, it should be possible to get them via control transfer like the test does?

I originally thought such a control transfer should end up doing _hid_get_device_descriptor() so I cannot comment on this without studying the code closer...

EDIT: OK, so the control transfer get the HID backend hard-coded values and they are compared to the "real" device descriptor that is retrieved and cached on enumeration. So I think the HID backend should rather use values from the cached device descriptor instead of the hard-coded values.

tormodvolden · 2023-12-13T13:19:44Z

I should probably make a separate merge request for this. Here, it would need partial reverting the previous commit to verify that this works (it seems to do). However I don't want to mess with the HID backend now in the release freeze.

Instead of filling in the blanks with hard-coded made-up values that are sometimes correct, use the cached descriptor values retrieved during enumeration, which should be a better fallback. References libusb#1360 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

tormodvolden · 2023-12-13T13:34:37Z

( I removed that HID fix from here, and rebased also.)

mcuee · 2023-12-15T13:41:13Z

Still the same problem.

MINGW64 /c/work/libusb/libusb_pr1360
$ make check
Making check in libusb
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/libusb'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/libusb'
Making check in examples
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/examples'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/examples'
Making check in tests
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
make  check-TESTS
make[2]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
make[3]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
PASS: stress.exe
FAIL: stress_mt.exe
PASS: set_option.exe
PASS: init_context.exe
============================================================================
Testsuite summary for libusb-1.0 1.0.27-rc1
============================================================================
# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to libusb-devel@lists.sourceforge.net
============================================================================
make[3]: *** [Makefile:800: test-suite.log] Error 1
make[3]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make[2]: *** [Makefile:908: check-TESTS] Error 2
make[2]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make[1]: *** [Makefile:1015: check-am] Error 2
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make: *** [Makefile:491: check-recursive] Error 1

$ ./tests/stress_mt.exe
Running multithreaded init/exit test...
Starting 8 threads
Running multithreaded init/exit test with enumeration...
Starting 8 threads
No access to device 05e3:0612, skipping transfer tests.
No access to device 8087:0026, skipping transfer tests.
Thread 0 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 1 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 2 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 3 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 4 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 5 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 6 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
Thread 7 failed (iteration 1): LIBUSB_ERROR_NOT_FOUND
All threads discovered 0 devices (2 not opened)
All done, 8 errors

RReverser · 2023-12-15T13:44:11Z

LIBUSB_ERROR_NOT_FOUND

Hm seems like a different problem, the one above was LIBUSB_ERROR_NOT_SUPPORTED.

mcuee · 2023-12-15T13:58:20Z

LIBUSB_ERROR_NOT_FOUND

Hm seems like a different problem, the one above was LIBUSB_ERROR_NOT_SUPPORTED.

It is the same issue. Devices with unsuported driver under Windows may return the following errors.

	/** Access denied (insufficient permissions) */
	LIBUSB_ERROR_ACCESS = -3,

	/** Entity not found */
	LIBUSB_ERROR_NOT_FOUND = -5,

	/** Operation not supported or unimplemented on this platform */
	LIBUSB_ERROR_NOT_SUPPORTED = -12,

You have to skip opening devices with unsupported device driver, as what is done for testlibusb.

Please refer to the comments in the test matrix and run log of testlibusb.
#1372 (comment)

Some device descriptor fields are hard-coded by the HID backend, so they will often not match. It is complicated to narrow this down to HID devices, so we simply ignore these fields on Windows wholesale. Hopefully we will fix the HID backend later, and this workaround can then be reverted. References libusb#1360 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

mcuee · 2023-12-17T09:17:58Z

@tormodvolden

Your latest commit is good. Now make check is okay under Windows.

MINGW64 /c/work/libusb/libusb_pr1360
$ make check
Making check in libusb
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/libusb'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/libusb'
Making check in examples
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/examples'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/examples'
Making check in tests
make[1]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
make  check-TESTS
make[2]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
make[3]: Entering directory '/c/work/libusb/libusb_pr1360/tests'
PASS: stress.exe
PASS: stress_mt.exe
PASS: set_option.exe
PASS: init_context.exe
============================================================================
Testsuite summary for libusb-1.0 1.0.27-rc1
============================================================================
# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
make[3]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make[2]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360/tests'
make[1]: Entering directory '/c/work/libusb/libusb_pr1360'
make[1]: Leaving directory '/c/work/libusb/libusb_pr1360'

MINGW64 /c/work/libusb/libusb_pr1360
$ ./tests/stress_mt.exe
Running multithreaded init/exit test...
Starting 8 threads
Running multithreaded init/exit test with enumeration...
Starting 8 threads
No access to device 05e3:0612, skipping transfer tests.
No access to device 8087:0026, skipping transfer tests.
No access to device 05e3:0610, skipping transfer tests.
No access to device 1c7a:0575, skipping transfer tests.
No access to device 8086:a0ed, skipping transfer tests.
No access to device 0925:7001, skipping transfer tests.
No access to device 04f2:b6dd, skipping transfer tests.
No access to device 8086:9a13, skipping transfer tests.
All threads discovered 9 devices (8 not opened)
All done, 0 errors

mcuee · 2023-12-18T02:00:02Z

This PR should be good to go.

Depending on the devices or drivers, open() may return LIBUSB_ERROR_ACCESS LIBUSB_ERROR_NOT_FOUND LIBUSB_ERROR_NOT_SUPPORTED for devices "out of reach" to libusb. References #1360 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

Some device descriptor fields are hard-coded by the HID backend, so they will often not match. It is complicated to narrow this down to HID devices, so we simply ignore these fields on Windows wholesale. Hopefully we will fix the HID backend later, and this workaround can then be reverted. References #1360 References #1378 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

Follow-up to libusb#1349.

mcuee added the build_ci Build system, CI label Dec 5, 2023

mcuee added the windows label Dec 5, 2023

tormodvolden mentioned this pull request Dec 12, 2023

1.0.27-rc1 test matrix #1372

Closed

25 tasks

tormodvolden pushed a commit that referenced this pull request Dec 12, 2023

tests/stress_mt: Stop early if any device fails

87d6686

Previously the loop would continue even if error has already occured since `goto close` alone doesn't stop early. References #1360

tormodvolden mentioned this pull request Dec 13, 2023

windows: Base HID device descriptor on cached values #1378

Open

tormodvolden force-pushed the windows-tests branch from edfee49 to c6bae8d Compare December 13, 2023 13:33

tormodvolden force-pushed the windows-tests branch from c6bae8d to c226c29 Compare December 15, 2023 14:29

mcuee mentioned this pull request Dec 18, 2023

Failed to open the device: Access denied (insufficient permissions) #1383

Closed

RReverser added 2 commits December 19, 2023 01:19

Run tests for AppVeyor too

e5b4246

Follow-up to libusb#1349.

Print vid:pid for failing device

2b727a1

tormodvolden force-pushed the windows-tests branch from c226c29 to 2b727a1 Compare December 19, 2023 00:20

mcuee mentioned this pull request Dec 26, 2023

libusb_open returns error codes other than LIBUSB_ERROR_ACCESS #1402

Open

mcuee mentioned this pull request Feb 1, 2024

Misc: To release 1.0.28 #1453

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run tests for AppVeyor too #1360

Run tests for AppVeyor too #1360

RReverser commented Dec 5, 2023

RReverser commented Dec 5, 2023

mcuee commented Dec 5, 2023

RReverser commented Dec 5, 2023

RReverser commented Dec 5, 2023 •

edited

RReverser commented Dec 5, 2023

mcuee commented Dec 5, 2023

mcuee commented Dec 5, 2023

RReverser commented Dec 5, 2023

tormodvolden commented Dec 13, 2023 •

edited

RReverser commented Dec 13, 2023

RReverser commented Dec 13, 2023

tormodvolden commented Dec 13, 2023

RReverser commented Dec 13, 2023

tormodvolden commented Dec 13, 2023 •

edited

tormodvolden commented Dec 13, 2023

tormodvolden commented Dec 13, 2023

mcuee commented Dec 15, 2023 •

edited

RReverser commented Dec 15, 2023

mcuee commented Dec 15, 2023

mcuee commented Dec 17, 2023

mcuee commented Dec 18, 2023

Run tests for AppVeyor too #1360

Are you sure you want to change the base?

Run tests for AppVeyor too #1360

Conversation

RReverser commented Dec 5, 2023

RReverser commented Dec 5, 2023

mcuee commented Dec 5, 2023

RReverser commented Dec 5, 2023

RReverser commented Dec 5, 2023 • edited

RReverser commented Dec 5, 2023

mcuee commented Dec 5, 2023

mcuee commented Dec 5, 2023

RReverser commented Dec 5, 2023

tormodvolden commented Dec 13, 2023 • edited

RReverser commented Dec 13, 2023

RReverser commented Dec 13, 2023

tormodvolden commented Dec 13, 2023

RReverser commented Dec 13, 2023

tormodvolden commented Dec 13, 2023 • edited

tormodvolden commented Dec 13, 2023

tormodvolden commented Dec 13, 2023

mcuee commented Dec 15, 2023 • edited

RReverser commented Dec 15, 2023

mcuee commented Dec 15, 2023

mcuee commented Dec 17, 2023

mcuee commented Dec 18, 2023

RReverser commented Dec 5, 2023 •

edited

tormodvolden commented Dec 13, 2023 •

edited

tormodvolden commented Dec 13, 2023 •

edited

mcuee commented Dec 15, 2023 •

edited