Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
Hi, my compiler is Clang on MacOS 10.7.5. I run ./configure --disable-log --prefix=/opt/local make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6" and here's the output: Making all in libusb CC libusb_1_0_la-core.lo core.c:1755:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ^ ~~~ core.c:1755:30: note: use '&' for a bitwise operation return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ^~ & core.c:1755:30: note: remove constant to silence this warning return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ~^~ core.c:1757:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ^ ~~ core.c:1757:30: note: use '&' for a bitwise operation return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ^~ & core.c:1757:30: note: remove constant to silence this warning return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ~^ 2 warnings generated. core.c:1755:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ^ ~~~ core.c:1755:30: note: use '&' for a bitwise operation return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ^~ & core.c:1755:30: note: remove constant to silence this warning return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); ~^~ core.c:1757:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ^ ~~ core.c:1757:30: note: use '&' for a bitwise operation return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ^~ & core.c:1757:30: note: remove constant to silence this warning return (usbi_backend->caps && USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); ~^ 2 warnings generated. CC libusb_1_0_la-descriptor.lo CC libusb_1_0_la-io.lo CC libusb_1_0_la-sync.lo CC libusb_1_0_la-darwin_usb.lo CC libusb_1_0_la-threads_posix.lo CCLD libusb-1.0.la best regards, nicolas Le 03/04/13 21:28, Pete Batard a écrit : > Hi, > > The 2nd release candidate for libusbx v1.0.15 is now available at > http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ > > This version brings the following improvements: > * Improve tranfer cancellation and avoid short read failures on broken > descriptors > * Filter out 8-bit characters in libusb_get_string_descriptor_ascii() > * Add WinCE support > * Add library stress tests > * Add FX3 firmware upload support for fxload > * Add HID and kernel driver detach support capabilities detection > * Add SuperSpeed detection on OS X > * Don't assume an high speed for isochronous or an interval or 1 on OS X > * Fix issues with autoclaim, composite HID devices, interface autoclaim > and early abort in libusb_close() on Windows. Also add VS 2012 > solution files. > * Improve fd event handling on Linux > * Other bug fixes and improvements > > For more details, please see the libusbx git log at: > https://github.com/libusbx/libusbx/commits/master > > If you have an application relying on libusb or libusbx, or are a > distribution maintainer, you are encouraged to test this RC and report > any issues to the libusbx mailing list before the planned release due on > 2013.04.14. > > For more info, please visit http://libusbx.org > > Regards, > > /Pete > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.source
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On Thu, Apr 4, 2013 at 4:27 PM, nico wrote: > Hi, > my compiler is Clang on MacOS 10.7.5. > I run > ./configure --disable-log --prefix=/opt/local > make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6" > and here's the output: > > Making all in libusb >CC libusb_1_0_la-core.lo > core.c:1755:30: warning: use of logical '&&' with constant operand > [-Wconstant-logical-operand] > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^ ~~~ > core.c:1755:30: note: use '&' for a bitwise operation > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^~ > & > core.c:1755:30: note: remove constant to silence this warning > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ~^~ > core.c:1757:30: warning: use of logical '&&' with constant operand > [-Wconstant-logical-operand] > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ^ > ~~ > core.c:1757:30: note: use '&' for a bitwise operation > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ^~ > & > core.c:1757:30: note: remove constant to silence this warning > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ~^ > 2 warnings generated. > core.c:1755:30: warning: use of logical '&&' with constant operand > [-Wconstant-logical-operand] > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^ ~~~ > core.c:1755:30: note: use '&' for a bitwise operation > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^~ > & > core.c:1755:30: note: remove constant to silence this warning > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ~^~ > core.c:1757:30: warning: use of logical '&&' with constant operand > [-Wconstant-logical-operand] > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ^ > ~~ > core.c:1757:30: note: use '&' for a bitwise operation > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ^~ > & > core.c:1757:30: note: remove constant to silence this warning > return (usbi_backend->caps && > USBI_CAP_SUPPORTS_DETACH_KERNEL_DRIVER); > ~^ > 2 warnings generated. Yes you are right. If using Apple gcc, then there are no warnings. If using clang, then yes two warnings are generated. Tested under Mac OS X 10.7.5. -- Xiaofan -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On Thu, Apr 4, 2013 at 6:24 PM, Xiaofan Chen wrote:
> Yes you are right. If using Apple gcc, then there are no warnings.
> If using clang, then yes two warnings are generated. Tested
> under Mac OS X 10.7.5.
Another thing for Mac OS X, I probably misled Nathan on
the bInterval fix.
The following lines should be removed,
https://github.com/libusbx/libusbx/commit/2ffefc04769845dcb682655a437fa604e0299683
+ /* work around buggy devices */
+ if (0 == interval) {
+interval = 9;
+ }
+
Discussion here:
http://libusb.6.n5.nabble.com/libusb-165-Darwin-submit-iso-transfer-assumes-HS-device-tp5711532p5711660.html
--
Xiaofan
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc1 is now available
On 03/04/13 20:35, Pete Batard wrote: On 2013.04.03 12:09, Toby Gray wrote: The attached patch fixes this. Thanks for testing. Your patch is now part of RC2, and I confirmed that RC2 compiled for WinCE on my test environment. Agreed. RC2 works fine for me too. If I provide a zip of pre-built binaries for WinCE would you be happy to host them in the libusbx downloads? Absolutely! If you provide your SourceForge ID, we should be able to grant you upload rights on the SF file repo. I'm thinking of replacing the sources/ and Windows/ subdirectories for each release to sources/ and binaries/, so you could fit right into the latter. Sounds good. My SourceForge ID is toby-gray. Is there a script you use to generate the zip of the pre-built desktop binaries? Or do you just use the scripts in .private and do some manual copying? I just use the .private scripts, and run bd from WDK and bm from MinGW-w64. Haven't bothered with updating the upload for now. If you want to add some scripts for CE builds in .private, that can be arranged too. I've attached a patch for adding a WinCE build script to the .private directory: 0002-WinCE-Adding-build-script-for-WinCE-binaries.patch I've also attached another patch which fixes x86 builds for WinCE: 0001-WinCE-Fixing-x86-build-on-Visual-Studio-2005.patch I'm happy for the inclusion of these patches to be delayed until 1.0.15 is out. Although if we do get an RC3 then it'd be great if they could be in it. If they aren't then I'll skip pre-built WinCE x86 binaries for this release. Regards, Toby >From e5f6c5df8c8fc9235e6c6ebbc2137348c11777fd Mon Sep 17 00:00:00 2001 From: Toby Gray Date: Thu, 4 Apr 2013 13:32:31 +0100 Subject: [PATCH 2/2] WinCE: Adding build script for WinCE binaries. --- .private/bwince.cmd| 55 .private/wbs_wince.txt | 37 2 files changed, 92 insertions(+), 0 deletions(-) create mode 100755 .private/bwince.cmd create mode 100755 .private/wbs_wince.txt diff --git a/.private/bwince.cmd b/.private/bwince.cmd new file mode 100755 index 000..a535dce --- /dev/null +++ b/.private/bwince.cmd @@ -0,0 +1,55 @@ +@echo off +rem produce the Win CE binary files for snapshots +rem !!!THIS SCRIPT IS FOR INTERNAL DEVELOPER USE ONLY!!! + +if "x%VSINSTALLDIR%"=="x" goto usage + +if "x%WINCE_TARGET_DIR_BASE%"=="x" set WINCE_TARGET_DIR_BASE=E:\dailies +if "x%WINCE_TARGET_ARCHES%"=="x" set WINCE_TARGET_ARCHES=ARMV4I MIPSII MIPSII_FP MIPSIV MIPSIV_FP SH4 x86 + + +set WINCE_TARGET_DIR=%WINCE_TARGET_DIR_BASE%\%DATE:/=-% +set MSBUILD_CMD=msbuild.exe +set MSBUILD_TARGET=Rebuild +set MSBUILD_CONFIGURATION=Release +set WINCE_SLN=msvc\libusbx_wince.sln +set PLATFORM_PREFIX=STANDARDSDK_500 ( +set PLATFORM_POSTFIX=) + + +set PWD=%~dp0 +cd .. + +mkdir %WINCE_TARGET_DIR% +mkdir %WINCE_TARGET_DIR%\include\libusbx-1.0 +copy libusb\libusb-1.0.def %WINCE_TARGET_DIR% +copy libusb\libusb.h %WINCE_TARGET_DIR%\include\libusbx-1.0 +for %%A in (%WINCE_TARGET_ARCHES%) do mkdir %WINCE_TARGET_DIR%\%%A +for %%A in (%WINCE_TARGET_ARCHES%) do mkdir %WINCE_TARGET_DIR%\%%A\static +for %%A in (%WINCE_TARGET_ARCHES%) do mkdir %WINCE_TARGET_DIR%\%%A\dll +for %%A in (%WINCE_TARGET_ARCHES%) do mkdir %WINCE_TARGET_DIR%\examples\%%A +mkdir %WINCE_TARGET_DIR%\examples\source +copy examples\listdevs.c %WINCE_TARGET_DIR%\examples\source +copy examples\xusb.c %WINCE_TARGET_DIR%\examples\source +copy msvc\stdint.h %WINCE_TARGET_DIR%\examples\source +copy .private\wbs_wince.txt %WINCE_TARGET_DIR%\README.txt + +rem Perform the rebuild +for %%A in (%WINCE_TARGET_ARCHES%) do %MSBUILD_CMD% %WINCE_SLN% /property:Platform="%PLATFORM_PREFIX%%%A%PLATFORM_POSTFIX%" /property:Configuration=%MSBUILD_CONFIGURATION% /target:%MSBUILD_TARGET%" + + +rem Copy across the binaries +for %%A in (%WINCE_TARGET_ARCHES%) do ( + copy %%A\%MSBUILD_CONFIGURATION%\lib\libusb-1.0.lib %WINCE_TARGET_DIR%\%%A\static + copy %%A\%MSBUILD_CONFIGURATION%\examples\listdevs.exe %WINCE_TARGET_DIR%\examples\%%A + copy %%A\%MSBUILD_CONFIGURATION%\examples\xusb.exe %WINCE_TARGET_DIR%\examples\%%A + copy %%A\%MSBUILD_CONFIGURATION%\dll\libusb-1.0.lib %WINCE_TARGET_DIR%\%%A\dll + copy %%A\%MSBUILD_CONFIGURATION%\dll\libusb-1.0.dll %WINCE_TARGET_DIR%\%%A\dll ) + +goto done + +:usage +echo must be run in a Visual Studio 2005 build environment! + +:done +cd %PWD% \ No newline at end of file diff --git a/.private/wbs_wince.txt b/.private/wbs_wince.txt new file mode 100755 index 000..b835eea --- /dev/null +++ b/.private/wbs_wince.txt @@ -0,0 +1,37 @@ + libusbx 1.0 Windows CE binary snapshot - README + + * + * The latest version of this snapshot can always be downloaded at: * + * https://sourceforge.net/projects/libusbx/files/ * + * + +o Visual Studio: + - Open existing
[Libusbx-devel] Storing debug database for prebuilt binaries
Hi, I'm in the middle of tracking down (and hopefully fixing) a rare memory fault in the desktop Windows version of libusbx*. When the issue was reported by one of our internal testers it wasn't possible for me to decode the Windows Error Reporting (WER) information in any sensible way as I didn't have the .pdb files for libusbx. Would it make sense to create a zip of the symbols for the pre-compiled binaries available on sourceforge? I don't remember any users ever providing Window error report information (such as minidumps ) so I'm not sure that it would be worth the extra effort for the maintainer producing the pre-built binaries (i.e. Pete). Regards, Toby * - it seems to be caused by having one thread inside handle events while another thread is attempting to submit a transfer. The thread which is handling events attempts to dereference a null pointer when checking HasOverlappedIoCompletedSync inside windows_handle_events. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] Fix NULL pointer dereference in Windows and WinCE backends when reusing transfers
Hi, As I mentioned in a previous email, I've been tracking down a rare NULL pointer dereference in the windows desktop backend. The problem is that the backend private information for transfers wasn't getting correctly cleared before the transfer completion callback was called. This meant that the fake fd number inside the transfer still contained the old value. As there is a period of time where a transfer is in the flying transfer list but hasn't been submitted to the backend, this meant that the wrong transfer could be completed. The problematic sequence is along the lines of the following: 1. Client creates a transfer using libusb_alloc_transfer. Let's call this transfer A. 2. Transfer A is submitted, e.g. reading from bulk endpoint 0x81. 3. The backend assigns a fake fd of 1 to transfer A and then submits it to the OS. 4. The OS completes the request. 5. The backend detects this when next handling events and the client has the callbacks called. 6. Without the fix in this patch, transfer_priv->pollable_fd.fd still has a value of one. 7. Client creates a new transfer using libusb_alloc_transfer. Let's call this transfer B. 8. Transer B is submitted, e.g. reading from bulk endpoing 0x81 with infinite timeout. 9. The backend assigns a fake fd of 1 to transfer B and then submits it to the OS. 10. The client then submits transfer A, reading from bulk endpoint 0x82 with a timeout of 2 seconds. 11. Before the backend is given transfer A it is added to the flying transfer list. 12. The OS completes transfer B. 13. A separate thread starts to run and asks libusb to handle events. 14. The windows backend notices that fake fd 1 has been signalled and starts to look through the flying transfer list. 15. The windows backend finds transfer A as it is earlier in the flying transfer list as it has an earlier timeout and has the old fake fd value of 1 and thinks it's been completed. However the OVERLAPPED is NULL so it causes a NULL pointer dereference. Tracking this down was further complicated by the NULL pointer dereference taking a bit of time to handle. By which time the thread which was resubmitting transfer A had gone and updated the fd value and set a valid OVERLAPPED structure. The attached patch makes sure this can't happen by making sure windows_clear_transfer_priv correctly clears the pollable_fd. This means that step 15 in the above sequence correctly skips over transfer A as the fake fd value will be -1 (until the transfer is actually submitted to the OS). It's also a problem with the WinCE backend, so I've included a similar fix in the patch. I understand that this is probably too risky a change to get into 1.0.15, especially as no-one else seems to have reported it. Regards, Toby >From f9da0f7b1470f098ae76fee686562c5fcb17961d Mon Sep 17 00:00:00 2001 From: Toby Gray Date: Thu, 4 Apr 2013 16:27:21 +0100 Subject: [PATCH] Windows and WinCE: Correctly clear backend transfer private information. * Without this fix if a transfer is reused then there is a period of time between it being adding to the flying transfer list and submitted where the fd value will be the old fd value. * If this occurs at the same time as all of the following conditions then the incorrect transfer will be handled as having completed: * The old fd value in the reused transfer has been recycled for a currently pending transfer. * This other pending transfer has a later timeout than the reused transfer (so therefore comes later in the flying transfer list). * The other pending transfer completes, therefore signalling the fd. As the flying transfer list is examined in order when handling events, the resubmitted transfer with the old fd value will be considered as completed. This will generally cause a NULL pointer dereference as the OVERLAPPED structure was already freed. --- libusb/os/wince_usb.c |1 + libusb/os/windows_usb.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libusb/os/wince_usb.c b/libusb/os/wince_usb.c index e4f7c7b..b4eb904 100644 --- a/libusb/os/wince_usb.c +++ b/libusb/os/wince_usb.c @@ -594,6 +594,7 @@ static void wince_clear_transfer_priv( wfd.itransfer = NULL; CloseHandle(wfd.handle); usbi_free_fd(transfer_priv->pollable_fd.fd); + transfer_priv->pollable_fd = INVALID_WINFD; } static int wince_cancel_transfer( diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c index 7c2428d..9b5de45 100644 --- a/libusb/os/windows_usb.c +++ b/libusb/os/windows_usb.c @@ -1912,6 +1912,7 @@ static void windows_clear_transfer_priv(struct usbi_transfer *itransfer) struct windows_transfer_priv *transfer_priv = (struct windows_transfer_priv*)usbi_transfer_get_os_priv(itransfer); usbi_free_fd(transfer_priv->pollable_fd.fd); + transfer_priv->pollable_fd = INVALID_WINFD; safe_free(transfer_priv->hid_buffer); // When auto claim is in use, attempt to release the auto-claimed interface auto_relea
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
2013/4/4 nico > Hi, > my compiler is Clang on MacOS 10.7.5. > I run > ./configure --disable-log --prefix=/opt/local > make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6" > and here's the output: > > Making all in libusb >CC libusb_1_0_la-core.lo > core.c:1755:30: warning: use of logical '&&' with constant operand > [-Wconstant-logical-operand] > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^ ~~~ > core.c:1755:30: note: use '&' for a bitwise operation > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ^~ > & > core.c:1755:30: note: remove constant to silence this warning > return (usbi_backend->caps && USBI_CAP_HAS_HID_ACCESS); > ~^~ > It is not just a warning but a real bug. libusb_has_capability() could _not_ work. It is now fixed in https://github.com/libusbx/libusbx/commit/fed4f7e47f49523c6a9469a2b25c7d995b1ebcd6 Thanks -- Dr. Ludovic Rousseau -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On 2013.04.04 09:27, nico wrote: > Making all in libusb >CC libusb_1_0_la-core.lo > core.c:1755:30: warning: use of logical '&&' with constant operand Thanks for the report, and the test. This is now fixed in RC3, along with a couple minor issues. The new RC is available from: http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ Regards, /Pete -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Fix NULL pointer dereference in Windows and WinCE backends when reusing transfers
On 2013.04.04 17:04, Toby Gray wrote: > As I mentioned in a previous email, I've been tracking down a rare NULL > pointer dereference in the windows desktop backend. Thanks! > The problem is that the backend private information for transfers wasn't > getting correctly cleared before the transfer completion callback was > called. > > This meant that the fake fd number inside the transfer still contained > the old value. As there is a period of time where a transfer is in the > flying transfer list but hasn't been submitted to the backend, this > meant that the wrong transfer could be completed. > > The problematic sequence is along the lines of the following: > > 1. Client creates a transfer using libusb_alloc_transfer. Let's call > this transfer A. > 2. Transfer A is submitted, e.g. reading from bulk endpoint 0x81. > 3. The backend assigns a fake fd of 1 to transfer A and then submits it > to the OS. > 4. The OS completes the request. > 5. The backend detects this when next handling events and the client has > the callbacks called. > 6. Without the fix in this patch, transfer_priv->pollable_fd.fd still > has a value of one. > 7. Client creates a new transfer using libusb_alloc_transfer. Let's call > this transfer B. > 8. Transer B is submitted, e.g. reading from bulk endpoing 0x81 with > infinite timeout. > 9. The backend assigns a fake fd of 1 to transfer B and then submits it > to the OS. > 10. The client then submits transfer A, reading from bulk endpoint 0x82 > with a timeout of 2 seconds. > 11. Before the backend is given transfer A it is added to the flying > transfer list. > 12. The OS completes transfer B. > 13. A separate thread starts to run and asks libusb to handle events. > 14. The windows backend notices that fake fd 1 has been signalled and > starts to look through the flying transfer list. > 15. The windows backend finds transfer A as it is earlier in the flying > transfer list as it has an earlier timeout and has the old fake fd value > of 1 and thinks it's been completed. However the OVERLAPPED is NULL so > it causes a NULL pointer dereference. > > Tracking this down was further complicated by the NULL pointer > dereference taking a bit of time to handle. By which time the thread > which was resubmitting transfer A had gone and updated the fd value and > set a valid OVERLAPPED structure. > > The attached patch makes sure this can't happen by making sure > windows_clear_transfer_priv correctly clears the pollable_fd. This means > that step 15 in the above sequence correctly skips over transfer A as > the fake fd value will be -1 (until the transfer is actually submitted > to the OS). > > It's also a problem with the WinCE backend, so I've included a similar > fix in the patch. > > I understand that this is probably too risky a change to get into > 1.0.15, especially as no-one else seems to have reported it. Well this is a short patch, but I want to have a closer look at it before it gets pushed. In all likelihood, it'll be applied for the 1.0.15 release since resetting the pollable_fd after usbi_free_fd() is a harmless operation anyway. But I'd like to make sure there isn't more we need to look into. At any rate, thanks for investigating these hard to track issues. Much appreciated! Regards, /Pete -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Storing debug database for prebuilt binaries
On 2013.04.04 14:45, Toby Gray wrote: > Would it make sense to create a zip of the symbols for the pre-compiled > binaries available on sourceforge? Well, I guess if we do, we might as well make that part of the Windows binary generation process, since I get to generate them then. It's a simple matter of adding a couple of extra copy lines to the bd.cmd private script. The Windows binaries are not very large, and I'd expect the .pdb to compress well, so I'll see if I can work something out for 1.0.15. I think it's better to provide our binary users with more data than they can use than have them miss something that could come handy in case of issues. Regards, /Pete -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On 2013.04.04 14:08, Xiaofan Chen wrote:
> The following lines should be removed,
> https://github.com/libusbx/libusbx/commit/2ffefc04769845dcb682655a437fa604e0299683
> + /* work around buggy devices */
> + if (0 == interval) {
> +interval = 9;
> + }
> +
Oh yeah, this has been included in RC3, along with fixing some typos in
the ChangeLog. Please let me know if you see more typos, as these are
always nice to have corrected in time for the release.
Regards,
/Pete
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
Hi, merci beaucoup to everyone for your work... Le 04/04/13 20:35, Pete Batard a écrit : > On 2013.04.04 09:27, nico wrote: >> Making all in libusb >> CC libusb_1_0_la-core.lo >> core.c:1755:30: warning: use of logical '&&' with constant operand > Thanks for the report, and the test. > This is now fixed in RC3, along with a couple minor issues. > > The new RC is available from: > http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ RC3 builds fine with Clang on macOS 10.7.5 ++ Nicolas > > Regards, > > /Pete > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Fix NULL pointer dereference in Windows and WinCE backends when reusing transfers
On Fri, Apr 5, 2013 at 12:04 AM, Toby Gray wrote: > I understand that this is probably too risky a change to get into 1.0.15, > especially as no-one else seems to have reported it. There were past reports of issues under Windows XP and Windows 7 when using libusbx async API with multithreaded programs. I am not so sure if your issue is related to the reports or not though. https://github.com/libusbx/libusbx/issues/52 Or http://www.libusb.org/ticket/140 -- Xiaofan -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On Fri, Apr 5, 2013 at 3:04 AM, Pete Batard wrote:
> On 2013.04.04 14:08, Xiaofan Chen wrote:
>> The following lines should be removed,
>> https://github.com/libusbx/libusbx/commit/2ffefc04769845dcb682655a437fa604e0299683
>> + /* work around buggy devices */
>> + if (0 == interval) {
>> +interval = 9;
>> + }
>> +
>
> Oh yeah, this has been included in RC3, along with fixing some typos in
> the ChangeLog. Please let me know if you see more typos, as these are
> always nice to have corrected in time for the release.
The 1.0.15 changelog does not seem to have typo.
The sentence "Don't assume high speed for isochronous or an interval of 1
on OS X" does not sound right. Maybe it can be changed to "Fix bInterval
value interpretation under OS X".
There is a typo in 1.0.14 changelog. The word "concurent" in "with regards to
concurent use "should be "concurrent".
--
Xiaofan
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
