Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weakness in libusb_exit cleanup codes #1440

Open
mcuee opened this issue Jan 22, 2024 · 2 comments
Open

Weakness in libusb_exit cleanup codes #1440

mcuee opened this issue Jan 22, 2024 · 2 comments
Labels
core Related to common codes

Comments

@mcuee
Copy link
Member

mcuee commented Jan 22, 2024

From here:

@sonatique mentioned the following.

I guess that for some reason the faulting device is correctly unref'ed down to zero and freed, but still in the list at the end, causing the segfault when log wants to access its properties.

Code in question:

libusb/libusb/core.c

Lines 2629 to 2633 in 0929a2b

for_each_device(_ctx, dev) {
usbi_warn(_ctx, "device %d.%d still referenced",
dev->bus_number, dev->device_address);
DEVICE_CTX(dev) = NULL;
}

@mcuee mcuee added the core Related to common codes label Jan 22, 2024
@mcuee mcuee changed the title Weakness in libusb_exit cleanup Weakness in libusb_exit cleanup codes Jan 22, 2024
@mcuee
Copy link
Member Author

mcuee commented Jan 22, 2024

BTW, macOS backend seems to do it within the backend.

/* cleanup function to destroy cached devices. must be called with a lock on darwin_cached_devices_mutex */
static void darwin_cleanup_devices(void) {
struct darwin_cached_device *dev, *next;
list_for_each_entry_safe(dev, next, &darwin_cached_devices, list, struct darwin_cached_device) {
if (dev->refcount > 1) {
usbi_err(NULL, "device still referenced at libusb_exit");
}
darwin_deref_cached_device(dev);
}
}

@mcuee
Copy link
Member Author

mcuee commented Feb 7, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Related to common codes
Projects
None yet
Development

No branches or pull requests

1 participant