Hi,
I have noticed some behavior that I believe most users will find
undesirable. The situation is this:
1) The application opens a libusb device, which adds this to the poll fds
2) While the device is opened and IO is occurring, the device reboots or
otherwise disappears from USB
3) When the dev
Hi,
Thanks for the patch, pushed to master.
On 06/24/2013 01:31 PM, Toby Gray wrote:
> 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
Hi,
On 06/26/2013 03:30 PM, Hans de Goede wrote:
> Hi,
>
> Thanks for the patch, pushed to master.
On second thought, I've found a problem with your patch,
after your patch the code always unrefs dev, but if
usbi_get_device_by_session_id() succeeds it returns a
so called borrowed reference, so we
Hi,
On 06/25/2013 11:56 PM, Chris Dickens wrote:
> Sorry, here's the patch with correct whitespace.
Thanks for this, I thought that we were memsetting
things to 0 on creation, so that this would not be necessary,
but I was wrong.
Patch pushed.
Regards,
Hans
---
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.
---
libusb/core.c |2 ++
1 file changed, 2 insertions(+
Hi,
On 06/23/2013 04:51 PM, Xiaofan Chen wrote:
>> Hmm, can you run under gdb, and then do a backtrace when it hangs /
>> crashes (when it hangs first do ctrl+c to return to gdb).
>>
>> IE:
>>
>> gdb ./examples/listdevs
>>> run
>> ...
>>> bt
>
> A bit problematic to use gdb here.
>
> $ ./exampl
Hi,
On 06/25/2013 11:27 PM, Chris Dickens wrote:
> Hi,
>
> I have discovered that the libusb process's file mask affects how
> libusb_attach_kernel_driver() restores the driver. In my particular case, I
> am dealing with usblp, so the kernel enumerates /dev/usb/lpX device files.
> The /dev/usb
Hi,
On 06/26/2013 09:10 AM, Chris Dickens wrote:
> Hi,
>
> I have noticed some behavior that I believe most users will find undesirable.
> The situation is this:
>
> 1) The application opens a libusb device, which adds this to the poll fds
> 2) While the device is opened and IO is occurring, the
On 26/06/13 15:44, Hans de Goede wrote:
> Hi,
>
> On 06/26/2013 03:30 PM, Hans de Goede wrote:
>> Hi,
>>
>> Thanks for the patch, pushed to master.
> On second thought, I've found a problem with your patch,
> after your patch the code always unrefs dev, but if
> usbi_get_device_by_session_id() succ
Hi,
On 06/26/2013 05:26 PM, Toby Gray wrote:
> 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.
Th
Hi,
On Wed, Jun 26, 2013 at 8:34 AM, Hans de Goede wrote:
> Hi,
>
> Hmm, the libusb_poll call in get_device_list() should make this quite hard
> to trigger, this will only
> happen if udev has not yet read the kernel event, and send an event on its
> own socket. Which likely
> means that your se
Yes, devtmpfs. Linux Kernel is 2.6.32-358 (RHEL6).
Regards,
Chris
On Wed, Jun 26, 2013 at 8:23 AM, Hans de Goede wrote:
> Hi,
>
>
> On 06/25/2013 11:27 PM, Chris Dickens wrote:
>
>> Hi,
>>
>> I have discovered that the libusb process's file mask affects how
>> libusb_attach_kernel_driver() res
12 matches
Mail list logo