It is possible for the extra socket flags (available from 2.6.27 on) to be
defined but not available. Check for this case and set the flags correctly
on the netlink socket.
When a transfer is submitted, the device is referenced in libusb_submit_transfer()
and unreferenced in usbi_handle_transfer_completion(). This transfer could potentially
be freed by any user callback, or is freed by libusb if LIBUSB_TRANSFER_FREE_TRANSFER
is set in the flags. The call to unreference the device uses this potentially freed
memory. Reading the device handle beforehand will prevent this disaster.
* When the timer thread is created in windows_init(), it performs an
initialisation phase in which it uses QueryPerformanceFrequency() to determine
if there is a high resolution timer available, and sets hires_frequency and
hires_ticks_to_ps appropriately. However, since windows_init() does not wait for
this initialisation phase to complete, windows_clock_gettime() can be called
before hires_frequency and hires_ticks_to_ps have been updated. This can result
in windows_clock_gettime() temporarily returning real-time clock values even
though the platform supports a monotonic clock.
* See http://sourceforge.net/mailarchive/forum.php?thread_name=1373620013-3574-1-git-send-email-simon.haggett%40realvnc.com&forum_name=libusbx-devel
* When the timer thread is created in wince_init(), it performs an initialisation
phase in which it uses QueryPerformanceFrequency() to determine if there is a
high resolution timer available, and sets hires_frequency and hires_ticks_to_ps
appropriately. However, since wince_init() does not wait for this initialisation
phase to complete, wince_clock_gettime() can be called before hires_frequency
and hires_ticks_to_ps have been updated. This can result in
wince_clock_gettime() temporarily returning real-time clock values even though
the platform supports a monotonic clock.
* See http://sourceforge.net/mailarchive/forum.php?thread_name=1373619997-3535-1-git-send-email-simon.haggett%40realvnc.com&forum_name=libusbx-devel
For messages received on the hotplug pipe, the message was read via
usbi_read() (ssize_t) and compared against the size of the message
struct (size_t). usbi_read() returns -1 on an error condition, so some
systems can cast the ssize_t to size_t for the comparison, making it
equal to SIZE_MAX and causing the error check condition to incorrectly
evaluate to false.
Defensively set return-by-reference value to -1 in error condition
NB: The comments do not match the implementation.
Comments: "[return] the index of the configuration matching a specific
bConfigurationValue in the idx output parameter, or -1 if the config was
not found"
There is a code path where idx is never touched. Perhaps clients of the
function are careful to only read idx if the return value is success,
but also setting idx to -1 is much safer.
There shouldn't be any problems with any supported version of OSX in
converting a UInt64 to an unsigned long. They should be the same size
but even if they are not the session should still be unique.
Using pthread_cancel() presents the opportunity for deadlock, so
use a control pipe to cause the event thread to gracefully exit.
Inspired on the identical patch for linux_udev from Chris Dickens.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Using pthread_cancel() presents the opportunity for deadlock, so
use a control pipe to cause the event thread to gracefully exit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Using one lock for this is a bad idea, as we should not be holding any
locks used by the hotplug thread when trying to stop otherwise the stop
function may wait indefinetely in pthread_join, while the event-thread
is waiting for the lock the caller of the stop function holds.
Using 2 separate locks for this should fix this deadlock, which has been
reported here: https://bugzilla.redhat.com/show_bug.cgi?id=985484
Many thanks to Chris Dickens for figuring out the cause of this deadlock!
CC: Chris Dickens <christopher.a.dickens@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
These options were added in 2.6.27 and are not available on all kernels
that support netlink. Set these options using fcntl when SOCK_CLOEXEC and
SOCK_NONBLOCK are not available.
Closes#124.
Warnings:
os/linux_usbfs.c: In function 'linux_get_device_address':
os/linux_usbfs.c:620: warning: comparison is always false due to limited range of data type
os/linux_usbfs.c:624: warning: comparison is always false due to limited range of data type
os/linux_usbfs.c:628: warning: comparison is always false due to limited range of data type
os/linux_usbfs.c:628: warning: comparison is always false due to limited range of data type
The warning is:
libusb/Makefile.am:57: warning: source file 'os/threads_windows.c' is in a subdirectory,
libusb/Makefile.am:57: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Fixed by setting the subdir-objects option.
Closes#125.
These headers are required by netlink.h. I am not sure how this
worked at all. It certainly doesn't work with older versions of Linux
2.6.
References #124.
This commit should fix issues with active transfers when a device is
disconnected. The backend is responsible for making sure the completion
callbacks are made, not the hotplug code. This should fix a number of
issues including duplicate callbacks and segmentation faults.
References #124.
* Instead of passing NULL for the context to hotplug callbacks, if the
context happens to be the default context, always pass the explicit
context pointer.
Stop pretending that having a separate event handling thread is a bad thing,
specifically delete the "[this] option is not very nice either, but may be
the nicest option available to you if the "proper" approach can not be applied
to your application", which suggests that using poll integration into a main
loop is the one and only "proper" approach.
Instead clearly document there are 2 viable approaches, using a separate
thread, or poll integration into a main loop.
Also stop claiming that libusb does not use threads internally, as with
the new hotplug support this is no longer true.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This serves 2 purposes:
1) We use lazy free-ing of the callback structure, for it to be actually
free-ed usbi_hotplug_match() needs to be called. This ensures this actually
happens (rather then waiting for a hotplug event to arrive, and not freeing
the callback as long as no such event arrives).
2) It causes libusb_handle_events to return to its caller on a call to
libusb_hotplug_deregister_callback, which is very useful for apps which use
a thread to do their apps (hotplug) event handling, otherwise that thread will
hang when the app tries to stop until some event happens.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
So that the device parameter can be NULL, in combination with a 0
events parameter, to be used to force lazy deregistration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* fb4c208c33 broke cygwin compilation due to __GCC__ not being defined
* The actual issue is that __GNUC__ rather than __GCC__ should have been used all along
* Also fixes gettimeofday() usage for MinGW/Cygwin
* Also increase log buffer size to 1K, fix a broken fprintf in core.c and sort whitespaces
Prior to this change a single line of logging performing several fprintf.
This change gets all the data for a line to be logged in a single
fprintf call. This reduced the chances of writes from another thread
getting intermixed with a log line.
It also makes it easier to change where logs are output to in the future.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Due to alignment requirements, libusb_hotplug_message might have
some padding bytes.
This change makes sure that these padding bytes are
initialised. Valgrind no longer complains about passing uninitialised
data to the write system call.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Xiaofan encountered a crash while testing on openbsd. The main problem here is
libusb_exit doing hotplug cleanup on a non hotplug capable backend.
If the usb_devs list is non empty (*) at libusb_exit time with a non hotplug
capable backend, then the hotplug cleanup code will unref the devices
in the list. Assuming this is the last unref, then libusb_unref_device
will call usbi_disconnect_device, which will try to take the usb_devs_lock,
which is already hold by libusb_exit. Note that if this deadlock was not
there, that we then also would have a double list_del issue.
*) This should never happen, if it does either libusb or the app has a memleak,
or the app still holds a reference to the device. The latter is an application
bug, since device->ctx will be invalid after libusb_exit, so the application
should not hold references after calling libusb_exit.
In this case we have a memleak the libusb openbsd code causing the usb_devs
list to be non empty. This will be fixed in another commit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
After the "WinCE: Fix device reference leak which caused crash on
libusb_exit()" commit, the code always unref-s dev after adding it to
discovered_devs. But if dev comes from usbi_get_device_by_session_id()
it is a weak ref and as such should not be unreffed.
Instead of re-adding comlicate ref tracking logic, this patch fixes this with
a libusb_device_ref(dev) of dev comes from usbi_get_device_by_session_id(),
turning the weak ref into a strong ref.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The Windows CE device allocation code has always had a bug where it would
leak references to devices when they are allocated. This commit removes the
reference leak.
This leak was highlighted by the new hotplug code which now triggers a NULL
pointer dereference if not all devices are unreferenced before libusb_exit
is called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Nathan Hjelm