Repository navigation
libusb: fail hid_open_path() if the read thread can't be started - #843
Merged
Merged
Conversation
hidapi_thread_create() discarded the pthread_create() result, so hidapi_initialize_device() went on to wait on the two-party startup barrier even when no read thread existed, and hid_open_path() blocked forever (e.g. on EAGAIN under thread/resource limits). hidapi_thread_create() now returns the creation status (0 on success). On failure, hidapi_initialize_device() skips the startup barrier and the join, and goes through the existing error path that destroys the input ring, releases the interface and reattaches the kernel driver; hid_open_path() then reports "failed to initialize device". A custom thread model provided via HIDAPI_THREAD_MODEL_INCLUDE must now declare hidapi_thread_create() as returning int (0 on success, non-zero on failure). Add LibUsbReadThreadStartupTest, which compiles libusb/hid.c with pthread and device-level libusb calls interposed to cover both the injected creation failure and normal startup/close, without hardware. Fixes: #842 Related: #825, #829 Coverity CID: 1706123 Assisted-by: claude-code:claude-opus-5-5
On Android before API 24, hidapi_thread_pthread.h provides its own pthread_barrier_t and pthread_barrier_wait(), which the test's interposition of pthread_barrier_wait() collides with. Add the test only where a native pthread_barrier_wait() exists (checked with the thread library linked), and make the test say so explicitly if it is built elsewhere. The test also now always uses the bundled pthread thread model, even if a custom HIDAPI_THREAD_MODEL_INCLUDE is configured for the library. Reword the hidapi_thread_create() comment: pthread_create() doesn't guarantee the thread handle is left unchanged on failure. Assisted-by: claude-code:claude-opus-5-5
Remove the regression test and restore the test CMake file to the base version, leaving only the production thread-creation failure handling. Assisted-by: Codex:GPT-6
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the libusb backend, failed read-thread creation left
hid_open_path()waiting forever at the startup barrier (Coverity CID 1706123). The thread wrapper now returns the creation status, and failure follows the existing cleanup path: free the input ring, release the interface, restore the kernel driver and returnNULLwith an error.Custom
HIDAPI_THREAD_MODEL_INCLUDEimplementations must returnintfromhidapi_thread_create()(0 on success, nonzero on failure); see #829.Validation: the existing Linux ASan build and test suite pass; four virtual-device tests skip because the devices are unavailable. Codex reviewed the completed production change.
Fixes #842
Related to #825, #829 and #841.
Generated by Claude Code (Claude Opus 5.5); reviewed by Codex (GPT-6).
Assisted-by: claude-code:claude-opus-5-5
Assisted-by: Codex:GPT-6