Fix a rare race condition in the Libusb transfer handling code, which was leading to a use-after-free in some scenarios: this fixes #1065. Technically, the fix is "don't dereference a transfer struct after executing its callback".
The underlying root cause is that while one thread calls the transfer's callback, the other thread might already notice it and, if it's waiting for that particular transfer, destroy it. So by the time the first thread reaches the next line (the read from "transfer->flags"), the pointer can be a dangling one.
The commit doesn't add new tests, because it seems that the existing tests are sufficient for catching these kinds of bugs, even with a low probability.
Fix a rare race condition in the Libusb transfer handling code, which was leading to a use-after-free in some scenarios: this fixes #1065. Technically, the fix is "don't dereference a transfer struct after executing its callback".
The underlying root cause is that while one thread calls the transfer's callback, the other thread might already notice it and, if it's waiting for that particular transfer, destroy it. So by the time the first thread reaches the next line (the read from "transfer->flags"), the pointer can be a dangling one.
The commit doesn't add new tests, because it seems that the existing tests are sufficient for catching these kinds of bugs, even with a low probability.