threads_windows.c: Memory access violation #412
Labels
Comments
|
Please provide a debug log of libusb. |
|
I also get this error when running the following code: To produce the error, press the button "Run test()" in the frame that appears after running the code. Here is the error that I get: |
|
Please help to provide the debug log, set PYUSB_ERROR=debug and
LIBUSB_DEBUG=4 environment
variables and post the logs.
|
|
How do I set those variables? Also, where will the logs be generated to? |
|
Something like this under Windows command (I tested using a virtual env). |
|
Then post the log file. It will be something like this. |
|
Okay, I can reproduce this issue myself by running your program. |
|
Awesome. I'm glad you were able to reproduce it. |
|
It would be interesting to know later on if the debug logs actually helped you solve this particular issue or not (since you’ve been inclined not to touch this issue without one). I’m a developer myself and I know how frustrating it can be with bad bug reports so don’t get me wrong. I did provide you with the commit that introduced the issue and a likely cause for it. It looked like it wouldn’t take the author more than a couple of hours tops to figure out what went wrong. Priorities shifted at work right after this happened so couldn’t provide a log. |
|
@jite I can understand what you come from. And thanks for reporting the issue and provide a possible cause which is great. On the other hand, I have some issues with your comment. Firstly to ask for a debug log can usually help. Secondly you can see that "Priorities shifted at work right after this happened so couldn’t provide a log" and it only takes a few minutes to generate the debug log, not "a couple of hours". It can be difficult to find a couple of hours at your spare time working on open source projects like libusb. BTW, I do not know if it is really a couple of hours myself since I am not a programmer and I do not know much about the internal working mechanisms of libusb (mainly on technical support and testing side of the projects). |
|
same issue, any solutions or workaround? |
|
@JoshMayberry I did an initial investigation of what caused it and found that the mutex variable is most likely referenced after it’s been destroyed. I don’t know the internals of libusb and I’m not that familiar with Windows threading/locks to find the exact culprit. I did a quick workaround by initializing the mutex right after it’s destroyed so that any action towards ’mutex’ would be valid (from memory perspective). It’s not a proper fix but it worked as a temporary workaround. We’ve later seen other weird issues using libusb1 as backend (for a winusb device) to pyusb forcing us to move to libusb0-win32 backend instead. The big drawback doing so is that we need to install a device filter for our device pointing it to libusb0. What kind of usb device do you have? Winusb? @mcuee The circumstances were unfortunate. I didn’t see the request for the logs immediatly, and when I did we had scrapped the hardware for other reasons (and started with a new setup). I would have provided the logs if I easily could :) (Having that said though, I don’t think the logs would provide much help for this issue. I’ve narrowed down the commit and that’s usually enough to get a good grip of what might be wrong. Since the change involved rewriting locking on windows and it was a rather small commit, I found it rather likely that the author could find the issue pretty quickly with the information given.) |
|
@jite The USB device in particular that I am using is a USB/COM barcode scanner. But, I get this issue regardless of it being plugged in or not. I hope that answered your question. |
|
@jite I see. Thanks for the clarifications. Hopefully this issue can be fixed (if it is confirmed to be an issue with libusb and not pyusb) once Chris or others have time to look into this. |
|
Not so sure if this is related. |
|
Same as issue here in pyusb. |
|
Temporary workaround is to go back to libusb-1.0.21. |
The refcounting mechanism in pyusb is broken. The above log shows debug messages added within the ref/unref functions of libusb and the init/_finalize_object methods of pyusb. You can see that the _LibUSB backend object was finalized before all of the _Device objects were finalized. The warning from libusb during libusb_exit() even says "some libusb_devices were leaked". Applications are not allowed to reference a device after its context has been destroyed. Closing this since this is not a libusb issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Commit 4be3202 refactored the Windows locking handling. However when running pyusb (using libusb1 backend) on win10 (64bit/64bit Python) we ran into a problem while trying to find USB devices: it always gave an OSError exception: "access violation writing 0x0000000000000024". Worth noting is that it works fine to detect devices, however the object finalize/del stage fails.
Unsure if it's a problem in libusb or pyusb, but did some digging and found out that prior to the commit mentioned, it works fine. Anyway, what I suspect is causing the issue is that something references
mutexafterusbi_mutex_destroy()has been called (which runsDeleteCriticalSection(mutex)). Quick test of adding aInitializeCriticalSection(mutex)after the deletion eliminates the problem (while of course not a proper solution).The text was updated successfully, but these errors were encountered: