[Libusbx-devel] SIGSEGV in list_del / io.c

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
Hi all,

during the debug for the unplug issue reported, I encounter now SIGSEGVs on
other places:

I added some debug output to the libusb/io.c:

int usbi_handle_transfer_completion(struct usbi_transfer *itransfer,
        enum libusb_transfer_status status)
{
        struct libusb_transfer *transfer =
                USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
        struct libusb_context *ctx = TRANSFER_CTX(transfer);
        struct libusb_device_handle *handle = transfer->dev_handle;
        uint8_t flags;
        int r = 0;
        usbi_dbg("entered... %p",ctx);

        /* FIXME: could be more intelligent with the timerfd here. we don't need
         * to disarm the timerfd if there was no timer running, and we only need
         * to rearm the timerfd if the transfer that expired was the one with
         * the shortest timeout. */

        usbi_mutex_lock(&ctx->flying_transfers_lock);
        usbi_dbg("locked mutex %p %p",itransfer,&itransfer->list);
        usbi_dbg("list pointers %p
%p",itransfer->list.next,itransfer->list.prev);
        list_del(&itransfer->list);
        usbi_dbg("deleted list");

The corresponding output when removing the device is:

[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
entered... 0x884cdf0
[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion] locked
mutex 0x8813eb8 0x8813ebc
[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion] list
pointers (nil) (nil)
Caught a signal (11: SIGSEGV)

This can be easily explained because the list_del looks like this:

static inline void list_del(struct list_head *entry)
{
        entry->next->prev = entry->prev;
        entry->prev->next = entry->next;
        entry->next = entry->prev = NULL;
}

=> entry->next and entry->prev are already NULL! So this delete should never be
done, adding some checkings would be helpful.

But when adding a check against NULL for each prev and next in the list_del
before accessing them, the process does not die but stalls on another point when
trying to do a bulk read the device after connecting:

/lib/libusb-1.0.so.0:libusb_ref_device()
/lib/libusb-1.0.so.0:libusb_submit_transfer()

and the last libusb debug output lines are:

[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
entered... 0x884cdf0
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] locked
mutex 0x8813eb8 0x8813ebc
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] list
pointers (nil) (nil)
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] deleted
list
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] transfer
0x8813eec has callback 0xb708b0c0
[ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb] actual_length=0
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 3
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 4
[ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy device 2.57
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 5
[ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for handle done!
0x884cf40
[ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for handle done!
0x884cf40
[ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer] need 4 urbs for new
transfer with length 65536
[ 6.981000] [00001fa4] libusbx: debug [linux_netlink_read_message] netlink
hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4, removed: yes
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] starting
device disconnect...
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] lock
acquired...
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] getting device
by session... 0x884cdf0
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] device:
0x884f0b8

I don't know exactly how to proceed here - any hint would be appreciated.

Best regards,

Erik

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Chris Dickens
This line tells a lot of the story:

[ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy device 2.57

This can only happen when a device's refcount == 0, which should not happen while an active transfer is occurring. When a device is enumerated, its refcount is 1. When you open the device, its refcount is incremented. When you submit a transfer for a device, its refcount is incremented. So in the most simplistic case, a device's refcount is 3 while it is connected and a transfer is being processed. If a transfer is in process and the device is disconnected before the transfer is finished, its refcount will be decremented, so in the simplistic case it would now be 2. When the transfer finishes, its refcount will be decremented and should be 1, leaving the destruction of the device to happen when you close the device. The fact that it is being destroyed in usbi_handle_transfer_completion means that the device had to have been unrefed or closed elsewhere, and it looks like you may be using it again afterwards.

Do you have a hotplug callback registered? If so, what does it do with the device upon connection and disconnection?

Chris


On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull <[hidden email]> wrote:
Hi all,

during the debug for the unplug issue reported, I encounter now SIGSEGVs on
other places:

I added some debug output to the libusb/io.c:

int usbi_handle_transfer_completion(struct usbi_transfer *itransfer,
        enum libusb_transfer_status status)
{
        struct libusb_transfer *transfer =
                USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
        struct libusb_context *ctx = TRANSFER_CTX(transfer);
        struct libusb_device_handle *handle = transfer->dev_handle;
        uint8_t flags;
        int r = 0;
        usbi_dbg("entered... %p",ctx);

        /* FIXME: could be more intelligent with the timerfd here. we don't need
         * to disarm the timerfd if there was no timer running, and we only need
         * to rearm the timerfd if the transfer that expired was the one with
         * the shortest timeout. */

        usbi_mutex_lock(&ctx->flying_transfers_lock);
        usbi_dbg("locked mutex %p %p",itransfer,&itransfer->list);
        usbi_dbg("list pointers %p
%p",itransfer->list.next,itransfer->list.prev);
        list_del(&itransfer->list);
        usbi_dbg("deleted list");

The corresponding output when removing the device is:

[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
entered... 0x884cdf0
[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion] locked
mutex 0x8813eb8 0x8813ebc
[ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion] list
pointers (nil) (nil)
Caught a signal (11: SIGSEGV)

This can be easily explained because the list_del looks like this:

static inline void list_del(struct list_head *entry)
{
        entry->next->prev = entry->prev;
        entry->prev->next = entry->next;
        entry->next = entry->prev = NULL;
}

=> entry->next and entry->prev are already NULL! So this delete should never be
done, adding some checkings would be helpful.

But when adding a check against NULL for each prev and next in the list_del
before accessing them, the process does not die but stalls on another point when
trying to do a bulk read the device after connecting:

/lib/libusb-1.0.so.0:libusb_ref_device()
/lib/libusb-1.0.so.0:libusb_submit_transfer()

and the last libusb debug output lines are:

[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
entered... 0x884cdf0
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] locked
mutex 0x8813eb8 0x8813ebc
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] list
pointers (nil) (nil)
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] deleted
list
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] transfer
0x8813eec has callback 0xb708b0c0
[ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb] actual_length=0
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 3
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 4
[ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy device 2.57
[ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion] part 5
[ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for handle done!
0x884cf40
[ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for handle done!
0x884cf40
[ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer] need 4 urbs for new
transfer with length 65536
[ 6.981000] [00001fa4] libusbx: debug [linux_netlink_read_message] netlink
hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4, removed: yes
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] starting
device disconnect...
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] lock
acquired...
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] getting device
by session... 0x884cdf0
[ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] device:
0x884f0b8

I don't know exactly how to proceed here - any hint would be appreciated.

Best regards,

Erik

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
Hi Chris,

thanks for your interesting explanation.

No, I haven't registered any callbacks. I'm using the connect to an
interface and doing bulk reads and bulk writes - no async handling. I would
expect to get a libusb return code that tells me "hey the device is no
longer there" on which I could react safely - and not getting a SEGV.

If I add a usleep(1000) as the first line in the discard-urb routines
everything goes fine - no SEGV.

Best regards,

Erik


Chris Dickens wrote:

> This line tells a lot of the story:
>
> [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy device 2.57
>
> This can only happen when a device's refcount == 0, which should not happen
> while an active transfer is occurring. When a device is enumerated, its
> refcount is 1. When you open the device, its refcount is incremented. When
> you submit a transfer for a device, its refcount is incremented. So in the
> most simplistic case, a device's refcount is 3 while it is connected and a
> transfer is being processed. If a transfer is in process and the device is
> disconnected before the transfer is finished, its refcount will be
> decremented, so in the simplistic case it would now be 2. When the transfer
> finishes, its refcount will be decremented and should be 1, leaving the
> destruction of the device to happen when you close the device. The fact
> that it is being destroyed in usbi_handle_transfer_completion means that
> the device had to have been unrefed or closed elsewhere, and it looks like
> you may be using it again afterwards.
>
> Do you have a hotplug callback registered? If so, what does it do with the
> device upon connection and disconnection?
>
> Chris
>
>
> On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>
>     during the debug for the unplug issue reported, I encounter now SIGSEGVs on
>     other places:
>
>     I added some debug output to the libusb/io.c:
>
>     int usbi_handle_transfer_completion(struct usbi_transfer *itransfer,
>              enum libusb_transfer_status status)
>     {
>              struct libusb_transfer *transfer =
>                      USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
>              struct libusb_context *ctx = TRANSFER_CTX(transfer);
>              struct libusb_device_handle *handle = transfer->dev_handle;
>              uint8_t flags;
>              int r = 0;
>              usbi_dbg("entered... %p",ctx);
>
>              /* FIXME: could be more intelligent with the timerfd here. we
>     don't need
>               * to disarm the timerfd if there was no timer running, and we
>     only need
>               * to rearm the timerfd if the transfer that expired was the
>     one with
>               * the shortest timeout. */
>
>              usbi_mutex_lock(&ctx->flying_transfers_lock);
>              usbi_dbg("locked mutex %p %p",itransfer,&itransfer->list);
>              usbi_dbg("list pointers %p
>     %p",itransfer->list.next,itransfer->list.prev);
>              list_del(&itransfer->list);
>              usbi_dbg("deleted list");
>
>     The corresponding output when removing the device is:
>
>     [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
>     entered... 0x884cdf0
>     [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
>     locked
>     mutex 0x8813eb8 0x8813ebc
>     [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
>     list
>     pointers (nil) (nil)
>     Caught a signal (11: SIGSEGV)
>
>     This can be easily explained because the list_del looks like this:
>
>     static inline void list_del(struct list_head *entry)
>     {
>              entry->next->prev = entry->prev;
>              entry->prev->next = entry->next;
>              entry->next = entry->prev = NULL;
>     }
>
>     => entry->next and entry->prev are already NULL! So this delete should
>     never be
>     done, adding some checkings would be helpful.
>
>     But when adding a check against NULL for each prev and next in the list_del
>     before accessing them, the process does not die but stalls on another
>     point when
>     trying to do a bulk read the device after connecting:
>
>     /lib/libusb-1.0.so.0:libusb_ref_device()
>     /lib/libusb-1.0.so.0:libusb_submit_transfer()
>
>     and the last libusb debug output lines are:
>
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     entered... 0x884cdf0
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     locked
>     mutex 0x8813eb8 0x8813ebc
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     list
>     pointers (nil) (nil)
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     deleted
>     list
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     transfer
>     0x8813eec has callback 0xb708b0c0
>     [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb] actual_length=0
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     part 3
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     part 4
>     [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy
>     device 2.57
>     [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
>     part 5
>     [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
>     handle done!
>     0x884cf40
>     [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
>     handle done!
>     0x884cf40
>     [ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer] need 4
>     urbs for new
>     transfer with length 65536
>     [ 6.981000] [00001fa4] libusbx: debug [linux_netlink_read_message] netlink
>     hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4, removed: yes
>     [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] starting
>     device disconnect...
>     [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] lock
>     acquired...
>     [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected]
>     getting device
>     by session... 0x884cdf0
>     [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] device:
>     0x884f0b8
>
>     I don't know exactly how to proceed here - any hint would be appreciated.
>
>     Best regards,
>
>     Erik
>
>     ------------------------------------------------------------------------------
>     Android apps run on BlackBerry 10
>     Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>     Now with support for Jelly Bean, Bluetooth, Mapview and more.
>     Get your Android app in front of a whole new audience.  Start now.
>     http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>     _______________________________________________
>     libusbx-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
>


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Chris Dickens
Which version of libusb(x) are you using? This sounds like an issue that was present in an older version (fixed by commit 858b794cf10ff1ac76a4f453bed7645aa9709c44).

Chris


On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <[hidden email]> wrote:
Hi Chris,

thanks for your interesting explanation.

No, I haven't registered any callbacks. I'm using the connect to an interface and doing bulk reads and bulk writes - no async handling. I would expect to get a libusb return code that tells me "hey the device is no longer there" on which I could react safely - and not getting a SEGV.

If I add a usleep(1000) as the first line in the discard-urb routines everything goes fine - no SEGV.

Best regards,

Erik


Chris Dickens wrote:
This line tells a lot of the story:

[ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy device 2.57

This can only happen when a device's refcount == 0, which should not happen
while an active transfer is occurring. When a device is enumerated, its
refcount is 1. When you open the device, its refcount is incremented. When
you submit a transfer for a device, its refcount is incremented. So in the
most simplistic case, a device's refcount is 3 while it is connected and a
transfer is being processed. If a transfer is in process and the device is
disconnected before the transfer is finished, its refcount will be
decremented, so in the simplistic case it would now be 2. When the transfer
finishes, its refcount will be decremented and should be 1, leaving the
destruction of the device to happen when you close the device. The fact
that it is being destroyed in usbi_handle_transfer_completion means that
the device had to have been unrefed or closed elsewhere, and it looks like
you may be using it again afterwards.

Do you have a hotplug callback registered? If so, what does it do with the
device upon connection and disconnection?

Chris


On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi all,

    during the debug for the unplug issue reported, I encounter now SIGSEGVs on
    other places:

    I added some debug output to the libusb/io.c:

    int usbi_handle_transfer_completion(struct usbi_transfer *itransfer,
             enum libusb_transfer_status status)
    {
             struct libusb_transfer *transfer =
                     USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
             struct libusb_context *ctx = TRANSFER_CTX(transfer);
             struct libusb_device_handle *handle = transfer->dev_handle;
             uint8_t flags;
             int r = 0;
             usbi_dbg("entered... %p",ctx);

             /* FIXME: could be more intelligent with the timerfd here. we
    don't need
              * to disarm the timerfd if there was no timer running, and we
    only need
              * to rearm the timerfd if the transfer that expired was the
    one with
              * the shortest timeout. */

             usbi_mutex_lock(&ctx->flying_transfers_lock);
             usbi_dbg("locked mutex %p %p",itransfer,&itransfer->list);
             usbi_dbg("list pointers %p
    %p",itransfer->list.next,itransfer->list.prev);
             list_del(&itransfer->list);
             usbi_dbg("deleted list");

    The corresponding output when removing the device is:

    [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
    entered... 0x884cdf0
    [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
    locked
    mutex 0x8813eb8 0x8813ebc
    [ 6.973000] [00001d59] libusbx: debug [usbi_handle_transfer_completion]
    list
    pointers (nil) (nil)
    Caught a signal (11: SIGSEGV)

    This can be easily explained because the list_del looks like this:

    static inline void list_del(struct list_head *entry)
    {
             entry->next->prev = entry->prev;
             entry->prev->next = entry->next;
             entry->next = entry->prev = NULL;
    }

    => entry->next and entry->prev are already NULL! So this delete should
    never be
    done, adding some checkings would be helpful.

    But when adding a check against NULL for each prev and next in the list_del
    before accessing them, the process does not die but stalls on another
    point when
    trying to do a bulk read the device after connecting:

    /lib/libusb-1.0.so.0:libusb_ref_device()
    /lib/libusb-1.0.so.0:libusb_submit_transfer()

    and the last libusb debug output lines are:

    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    entered... 0x884cdf0
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    locked
    mutex 0x8813eb8 0x8813ebc
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    list
    pointers (nil) (nil)
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    deleted
    list
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    transfer
    0x8813eec has callback 0xb708b0c0
    [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb] actual_length=0
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    part 3
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    part 4
    [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy
    device 2.57
    [ 6.849000] [00001fae] libusbx: debug [usbi_handle_transfer_completion]
    part 5
    [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
    handle done!
    0x884cf40
    [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
    handle done!
    0x884cf40
    [ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer] need 4
    urbs for new
    transfer with length 65536
    [ 6.981000] [00001fa4] libusbx: debug [linux_netlink_read_message] netlink
    hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4, removed: yes
    [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] starting
    device disconnect...
    [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] lock
    acquired...
    [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected]
    getting device
    by session... 0x884cdf0
    [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected] device:
    0x884f0b8

    I don't know exactly how to proceed here - any hint would be appreciated.

    Best regards,

    Erik

    ------------------------------------------------------------------------------
    Android apps run on BlackBerry 10
    Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
    Now with support for Jelly Bean, Bluetooth, Mapview and more.
    Get your Android app in front of a whole new audience.  Start now.
    http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
    _______________________________________________
    libusbx-devel mailing list
    [hidden email]
    <mailto:[hidden email]>
    https://lists.sourceforge.net/lists/listinfo/libusbx-devel





------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
Hi Chris,

I'm using 1.0.17, the commit cannot be found on the git browser when taking
your ID, so I can't tell you if I have a too old version.
<http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44>

Would be nice if you could point me to the commit, thanks.

Best regards,

Erik


Chris Dickens wrote:

> Which version of libusb(x) are you using? This sounds like an issue that
> was present in an older version (fixed by commit
> 858b794cf10ff1ac76a4f453bed7645aa9709c44).
>
> Chris
>
>
> On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Chris,
>
>     thanks for your interesting explanation.
>
>     No, I haven't registered any callbacks. I'm using the connect to an
>     interface and doing bulk reads and bulk writes - no async handling. I
>     would expect to get a libusb return code that tells me "hey the device
>     is no longer there" on which I could react safely - and not getting a SEGV.
>
>     If I add a usleep(1000) as the first line in the discard-urb routines
>     everything goes fine - no SEGV.
>
>     Best regards,
>
>     Erik
>
>
>     Chris Dickens wrote:
>
>         This line tells a lot of the story:
>
>         [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy
>         device 2.57
>
>         This can only happen when a device's refcount == 0, which should
>         not happen
>         while an active transfer is occurring. When a device is enumerated, its
>         refcount is 1. When you open the device, its refcount is
>         incremented. When
>         you submit a transfer for a device, its refcount is incremented. So
>         in the
>         most simplistic case, a device's refcount is 3 while it is
>         connected and a
>         transfer is being processed. If a transfer is in process and the
>         device is
>         disconnected before the transfer is finished, its refcount will be
>         decremented, so in the simplistic case it would now be 2. When the
>         transfer
>         finishes, its refcount will be decremented and should be 1, leaving the
>         destruction of the device to happen when you close the device. The fact
>         that it is being destroyed in usbi_handle_transfer___completion
>         means that
>         the device had to have been unrefed or closed elsewhere, and it
>         looks like
>         you may be using it again afterwards.
>
>         Do you have a hotplug callback registered? If so, what does it do
>         with the
>         device upon connection and disconnection?
>
>         Chris
>
>
>         On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:erik.rull@rdsoftware.__de
>         <mailto:[hidden email]>>> wrote:
>
>              Hi all,
>
>              during the debug for the unplug issue reported, I encounter
>         now SIGSEGVs on
>              other places:
>
>              I added some debug output to the libusb/io.c:
>
>              int usbi_handle_transfer___completion(struct usbi_transfer
>         *itransfer,
>                       enum libusb_transfer_status status)
>              {
>                       struct libusb_transfer *transfer =
>                               USBI_TRANSFER_TO_LIBUSB___TRANSFER(itransfer);
>                       struct libusb_context *ctx = TRANSFER_CTX(transfer);
>                       struct libusb_device_handle *handle =
>         transfer->dev_handle;
>                       uint8_t flags;
>                       int r = 0;
>                       usbi_dbg("entered... %p",ctx);
>
>                       /* FIXME: could be more intelligent with the timerfd
>         here. we
>              don't need
>                        * to disarm the timerfd if there was no timer
>         running, and we
>              only need
>                        * to rearm the timerfd if the transfer that expired
>         was the
>              one with
>                        * the shortest timeout. */
>
>                       usbi_mutex_lock(&ctx->flying___transfers_lock);
>                       usbi_dbg("locked mutex %p
>         %p",itransfer,&itransfer->__list);
>                       usbi_dbg("list pointers %p
>              %p",itransfer->list.next,__itransfer->list.prev);
>                       list_del(&itransfer->list);
>                       usbi_dbg("deleted list");
>
>              The corresponding output when removing the device is:
>
>              [ 6.973000] [00001d59] libusbx: debug
>         [usbi_handle_transfer___completion]
>              entered... 0x884cdf0
>              [ 6.973000] [00001d59] libusbx: debug
>         [usbi_handle_transfer___completion]
>              locked
>              mutex 0x8813eb8 0x8813ebc
>              [ 6.973000] [00001d59] libusbx: debug
>         [usbi_handle_transfer___completion]
>              list
>              pointers (nil) (nil)
>              Caught a signal (11: SIGSEGV)
>
>              This can be easily explained because the list_del looks like this:
>
>              static inline void list_del(struct list_head *entry)
>              {
>                       entry->next->prev = entry->prev;
>                       entry->prev->next = entry->next;
>                       entry->next = entry->prev = NULL;
>              }
>
>              => entry->next and entry->prev are already NULL! So this
>         delete should
>              never be
>              done, adding some checkings would be helpful.
>
>              But when adding a check against NULL for each prev and next in
>         the list_del
>              before accessing them, the process does not die but stalls on
>         another
>              point when
>              trying to do a bulk read the device after connecting:
>
>              /lib/libusb-1.0.so.0:libusb___ref_device()
>              /lib/libusb-1.0.so.0:libusb___submit_transfer()
>
>              and the last libusb debug output lines are:
>
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              entered... 0x884cdf0
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              locked
>              mutex 0x8813eb8 0x8813ebc
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              list
>              pointers (nil) (nil)
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              deleted
>              list
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              transfer
>              0x8813eec has callback 0xb708b0c0
>              [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb]
>         actual_length=0
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              part 3
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              part 4
>              [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device]
>         destroy
>              device 2.57
>              [ 6.849000] [00001fae] libusbx: debug
>         [usbi_handle_transfer___completion]
>              part 5
>              [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
>              handle done!
>              0x884cf40
>              [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
>              handle done!
>              0x884cf40
>              [ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer]
>         need 4
>              urbs for new
>              transfer with length 65536
>              [ 6.981000] [00001fa4] libusbx: debug
>         [linux_netlink_read_message] netlink
>              hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4,
>         removed: yes
>              [ 6.981000] [00001fa4] libusbx: debug
>         [linux_device_disconnected] starting
>              device disconnect...
>              [ 6.981000] [00001fa4] libusbx: debug
>         [linux_device_disconnected] lock
>              acquired...
>              [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected]
>              getting device
>              by session... 0x884cdf0
>              [ 6.981000] [00001fa4] libusbx: debug
>         [linux_device_disconnected] device:
>              0x884f0b8
>
>              I don't know exactly how to proceed here - any hint would be
>         appreciated.
>
>              Best regards,
>
>              Erik
>
>
>         ------------------------------__------------------------------__------------------
>              Android apps run on BlackBerry 10
>              Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>              Now with support for Jelly Bean, Bluetooth, Mapview and more.
>              Get your Android app in front of a whole new audience.  Start now.
>         http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&__iu=/4140/ostg.clktrk
>         <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk>
>              _________________________________________________
>              libusbx-devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>              <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         https://lists.sourceforge.net/__lists/listinfo/libusbx-devel
>         <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>
>
>
>
>


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Chris Dickens
Hi Erik,

Sourceforge seems to not have anything past 1.0.12. You can see the commit on GitHub here (https://github.com/libusbx/libusbx/commit/858b794cf10ff1ac76a4f453bed7645aa9709c44). However 1.0.17 does indeed have this problem fixed.

Is 1.0.17 installed as a system package, or did you compile it yourself? I'm wondering if you are possibly linking to an older version at runtime.

Regards,
Chris

On Friday, February 14, 2014, Erik Rull <[hidden email]> wrote:
Hi Chris,

I'm using 1.0.17, the commit cannot be found on the git browser when taking your ID, so I can't tell you if I have a too old version.
<http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44>

Would be nice if you could point me to the commit, thanks.

Best regards,

Erik


Chris Dickens wrote:
Which version of libusb(x) are you using? This sounds like an issue that
was present in an older version (fixed by commit
858b794cf10ff1ac76a4f453bed7645aa9709c44).

Chris


On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Chris,

    thanks for your interesting explanation.

    No, I haven't registered any callbacks. I'm using the connect to an
    interface and doing bulk reads and bulk writes - no async handling. I
    would expect to get a libusb return code that tells me "hey the device
    is no longer there" on which I could react safely - and not getting a SEGV.

    If I add a usleep(1000) as the first line in the discard-urb routines
    everything goes fine - no SEGV.

    Best regards,

    Erik


    Chris Dickens wrote:

        This line tells a lot of the story:

        [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device] destroy
        device 2.57

        This can only happen when a device's refcount == 0, which should
        not happen
        while an active transfer is occurring. When a device is enumerated, its
        refcount is 1. When you open the device, its refcount is
        incremented. When
        you submit a transfer for a device, its refcount is incremented. So
        in the
        most simplistic case, a device's refcount is 3 while it is
        connected and a
        transfer is being processed. If a transfer is in process and the
        device is
        disconnected before the transfer is finished, its refcount will be
        decremented, so in the simplistic case it would now be 2. When the
        transfer
        finishes, its refcount will be decremented and should be 1, leaving the
        destruction of the device to happen when you close the device. The fact
        that it is being destroyed in usbi_handle_transfer___completion
        means that
        the device had to have been unrefed or closed elsewhere, and it
        looks like
        you may be using it again afterwards.

        Do you have a hotplug callback registered? If so, what does it do
        with the
        device upon connection and disconnection?

        Chris


        On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull <[hidden email]
        <mailto:[hidden email]>
        <mailto:erik.rull@rdsoftware.__de
        <mailto:[hidden email]>>> wrote:

             Hi all,

             during the debug for the unplug issue reported, I encounter
        now SIGSEGVs on
             other places:

             I added some debug output to the libusb/io.c:

             int usbi_handle_transfer___completion(struct usbi_transfer
        *itransfer,
                      enum libusb_transfer_status status)
             {
                      struct libusb_transfer *transfer =
                              USBI_TRANSFER_TO_LIBUSB___TRANSFER(itransfer);
                      struct libusb_context *ctx = TRANSFER_CTX(transfer);
                      struct libusb_device_handle *handle =
        transfer->dev_handle;
                      uint8_t flags;
                      int r = 0;
                      usbi_dbg("entered... %p",ctx);

                      /* FIXME: could be more intelligent with the timerfd
        here. we
             don't need
                       * to disarm the timerfd if there was no timer
        running, and we
             only need
                       * to rearm the timerfd if the transfer that expired
        was the
             one with
                       * the shortest timeout. */

                      usbi_mutex_lock(&ctx->flying___transfers_lock);
                      usbi_dbg("locked mutex %p
        %p",itransfer,&itransfer->__list);
                      usbi_dbg("list pointers %p
             %p",itransfer->list.next,__itransfer->list.prev);
                      list_del(&itransfer->list);
                      usbi_dbg("deleted list");

             The corresponding output when removing the device is:

             [ 6.973000] [00001d59] libusbx: debug
        [usbi_handle_transfer___completion]
             entered... 0x884cdf0
             [ 6.973000] [00001d59] libusbx: debug
        [usbi_handle_transfer___completion]
             locked
             mutex 0x8813eb8 0x8813ebc
             [ 6.973000] [00001d59] libusbx: debug
        [usbi_handle_transfer___completion]
             list
             pointers (nil) (nil)
             Caught a signal (11: SIGSEGV)

             This can be easily explained because the list_del looks like this:

             static inline void list_del(struct list_head *entry)
             {
                      entry->next->prev = entry->prev;
                      entry->prev->next = entry->next;
                      entry->next = entry->prev = NULL;
             }

             => entry->next and entry->prev are already NULL! So this
        delete should
             never be
             done, adding some checkings would be helpful.

             But when adding a check against NULL for each prev and next in
        the list_del
             before accessing them, the process does not die but stalls on
        another
             point when
             trying to do a bulk read the device after connecting:

             /lib/libusb-1.0.so.0:libusb___ref_device()
             /lib/libusb-1.0.so.0:libusb___submit_transfer()

             and the last libusb debug output lines are:

             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             entered... 0x884cdf0
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             locked
             mutex 0x8813eb8 0x8813ebc
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             list
             pointers (nil) (nil)
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             deleted
             list
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             transfer
             0x8813eec has callback 0xb708b0c0
             [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb]
        actual_length=0
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             part 3
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             part 4
             [ 6.849000] [00001fae] libusbx: debug [libusb_unref_device]
        destroy
             device 2.57
             [ 6.849000] [00001fae] libusbx: debug
        [usbi_handle_transfer___completion]
             part 5
             [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
             handle done!
             0x884cf40
             [ 6.849000] [00001fae] libusbx: debug [op_handle_events] Reap for
             handle done!
             0x884cf40
             [ 6.855000] [00001fae] libusbx: debug [submit_bulk_transfer]
        need 4
             urbs for new
             transfer with length 65536
             [ 6.981000] [00001fa4] libusbx: debug
        [linux_netlink_read_message] netlink
             hotplug found device busnum: 2, devaddr: 57, sys_name: 2-1.4,
        removed: yes
             [ 6.981000] [00001fa4] libusbx: debug
        [linux_device_disconnected] starting
             device disconnect...
             [ 6.981000] [00001fa4] libusbx: debug
        [linux_device_disconnected] lock
             acquired...
             [ 6.981000] [00001fa4] libusbx: debug [linux_device_disconnected]
             getting device
             by session... 0x884cdf0
             [ 6.981000] [00001fa4] libusbx: debug
        [linux_device_disconnected] device:
             0x884f0b8

             I don't know exactly how to proceed here - any hint would be
        appreciated.

             Best regards,

             Erik


        ------------------------------__------------------------------__------------------
             Android apps run on BlackBerry 10
             Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
             Now with support for Jelly Bean, Bluetooth, Mapview and more.
             Get your Android app in front of a whole new audience.  Start now.
        http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&__iu=/4140/ostg.clktrk
        <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk>
             _________________________________________________
             libusbx-devel mailing list
        libusbx-devel@lists.__sourceforge.net
        <mailto:[hidden email]>
             <mailto:libusbx-devel@lists.__sourceforge.net
        <mailto:[hidden email]>>
        https://lists.sourceforge.net/__lists/listinfo/libusbx-devel
        <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>






------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
Hi Chris,

thanks. I compiled it myself, the download is from here:
<http://sourceforge.net/projects/libusbx/files/releases/1.0.17/source/>
Maybe this is wrong, too?

What do you mean with linking to an older version at runtime? I don't have
another libusb-x.so.y on the target system so it's very unlikely that the
wrong file is selected. Additionally, I added some more debug output and
this is visible which lets me assume that the correct library was taken.

At compile time I explicitly add the path to the self compiled version, so
the libary should be taken. If I manually delete the .so file and try to
link my application, it fails. So the path at compile / link time should be
correct, too.
strace shows it:
[pid 12404] open("/home/erik/libusbx/.install/include/libusb-1.0",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
=> this is my selfcompiled version
and ldd points also to the correct version (different path due to my target
system) - but the library pointing to it is a copy of the lib linked
against above:
libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb70ba000)

Any further ideas?

Best regards,

Erik

Chris Dickens wrote:

> Hi Erik,
>
> Sourceforge seems to not have anything past 1.0.12. You can see the commit
> on GitHub here
> (https://github.com/libusbx/libusbx/commit/858b794cf10ff1ac76a4f453bed7645aa9709c44).
> However 1.0.17 does indeed have this problem fixed.
>
> Is 1.0.17 installed as a system package, or did you compile it yourself?
> I'm wondering if you are possibly linking to an older version at runtime.
>
> Regards,
> Chris
>
> On Friday, February 14, 2014, Erik Rull <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Chris,
>
>     I'm using 1.0.17, the commit cannot be found on the git browser when
>     taking your ID, so I can't tell you if I have a too old version.
>     <http://libusbx.git.__sourceforge.net/git/gitweb.__cgi?p=libusbx/libusbx;a=__commit;h=__858b794cf10ff1ac76a4f453bed764__5aa9709c44
>     <http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44>>
>
>     Would be nice if you could point me to the commit, thanks.
>
>     Best regards,
>
>     Erik
>
>
>     Chris Dickens wrote:
>
>         Which version of libusb(x) are you using? This sounds like an issue
>         that
>         was present in an older version (fixed by commit
>         858b794cf10ff1ac76a4f453bed764__5aa9709c44).
>
>         Chris
>
>
>         On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <[hidden email]
>         <mailto:[hidden email]>> wrote:
>
>              Hi Chris,
>
>              thanks for your interesting explanation.
>
>              No, I haven't registered any callbacks. I'm using the connect
>         to an
>              interface and doing bulk reads and bulk writes - no async
>         handling. I
>              would expect to get a libusb return code that tells me "hey
>         the device
>              is no longer there" on which I could react safely - and not
>         getting a SEGV.
>
>              If I add a usleep(1000) as the first line in the discard-urb
>         routines
>              everything goes fine - no SEGV.
>
>              Best regards,
>
>              Erik
>
>
>              Chris Dickens wrote:
>
>                  This line tells a lot of the story:
>
>                  [ 6.849000] [00001fae] libusbx: debug
>         [libusb_unref_device] destroy
>                  device 2.57
>
>                  This can only happen when a device's refcount == 0, which
>         should
>                  not happen
>                  while an active transfer is occurring. When a device is
>         enumerated, its
>                  refcount is 1. When you open the device, its refcount is
>                  incremented. When
>                  you submit a transfer for a device, its refcount is
>         incremented. So
>                  in the
>                  most simplistic case, a device's refcount is 3 while it is
>                  connected and a
>                  transfer is being processed. If a transfer is in process
>         and the
>                  device is
>                  disconnected before the transfer is finished, its refcount
>         will be
>                  decremented, so in the simplistic case it would now be 2.
>         When the
>                  transfer
>                  finishes, its refcount will be decremented and should be
>         1, leaving the
>                  destruction of the device to happen when you close the
>         device. The fact
>                  that it is being destroyed in
>         usbi_handle_transfer_____completion
>                  means that
>                  the device had to have been unrefed or closed elsewhere,
>         and it
>                  looks like
>                  you may be using it again afterwards.
>
>                  Do you have a hotplug callback registered? If so, what
>         does it do
>                  with the
>                  device upon connection and disconnection?
>
>                  Chris
>
>
>                  On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull
>         <[hidden email]
>                  <mailto:[hidden email]>
>                  <mailto:erik.rull@rdsoftware.__de
>                  <mailto:[hidden email]>>> wrote:
>
>                       Hi all,
>
>                       during the debug for the unplug issue reported, I
>         encounter
>                  now SIGSEGVs on
>                       other places:
>
>                       I added some debug output to the libusb/io.c:
>
>                       int usbi_handle_transfer_____completion(struct
>         usbi_transfer
>                  *itransfer,
>                                enum libusb_transfer_status status)
>                       {
>                                struct libusb_transfer *transfer =
>
>         USBI_TRANSFER_TO_LIBUSB_____TRANSFER(itransfer);
>                                struct libusb_context *ctx =
>         TRANSFER_CTX(transfer);
>                                struct libusb_device_handle *handle =
>                  transfer->dev_handle;
>                                uint8_t flags;
>                                int r = 0;
>                                usbi_dbg("entered... %p",ctx);
>
>                                /* FIXME: could be more intelligent with the
>         timerfd
>                  here. we
>                       don't need
>                                 * to disarm the timerfd if there was no timer
>                  running, and we
>                       only need
>                                 * to rearm the timerfd if the transfer that
>         expired
>                  was the
>                       one with
>                                 * the shortest timeout. */
>
>
>         usbi_mutex_lock(&ctx->flying_____transfers_lock);
>                                usbi_dbg("locked mutex %p
>                  %p",itransfer,&itransfer->____list);
>                                usbi_dbg("list pointers %p
>                       %p",itransfer->list.next,____itransfer->list.prev);
>                                list_del(&itransfer->list);
>                                usbi_dbg("deleted list");
>
>                       The corresponding output when removing the device is:
>
>                       [ 6.973000] [00001d59] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       entered... 0x884cdf0
>                       [ 6.973000] [00001d59] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       locked
>                       mutex 0x8813eb8 0x8813ebc
>                       [ 6.973000] [00001d59] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       list
>                       pointers (nil) (nil)
>                       Caught a signal (11: SIGSEGV)
>
>                       This can be easily explained because the list_del
>         looks like this:
>
>                       static inline void list_del(struct list_head *entry)
>                       {
>                                entry->next->prev = entry->prev;
>                                entry->prev->next = entry->next;
>                                entry->next = entry->prev = NULL;
>                       }
>
>                       => entry->next and entry->prev are already NULL! So this
>                  delete should
>                       never be
>                       done, adding some checkings would be helpful.
>
>                       But when adding a check against NULL for each prev
>         and next in
>                  the list_del
>                       before accessing them, the process does not die but
>         stalls on
>                  another
>                       point when
>                       trying to do a bulk read the device after connecting:
>
>                       /lib/libusb-1.0.so.0:libusb_____ref_device()
>                       /lib/libusb-1.0.so.0:libusb_____submit_transfer()
>
>                       and the last libusb debug output lines are:
>
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       entered... 0x884cdf0
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       locked
>                       mutex 0x8813eb8 0x8813ebc
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       list
>                       pointers (nil) (nil)
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       deleted
>                       list
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       transfer
>                       0x8813eec has callback 0xb708b0c0
>                       [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb]
>                  actual_length=0
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       part 3
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       part 4
>                       [ 6.849000] [00001fae] libusbx: debug
>         [libusb_unref_device]
>                  destroy
>                       device 2.57
>                       [ 6.849000] [00001fae] libusbx: debug
>                  [usbi_handle_transfer_____completion]
>                       part 5
>                       [ 6.849000] [00001fae] libusbx: debug
>         [op_handle_events] Reap for
>                       handle done!
>                       0x884cf40
>                       [ 6.849000] [00001fae] libusbx: debug
>         [op_handle_events] Reap for
>                       handle done!
>                       0x884cf40
>                       [ 6.855000] [00001fae] libusbx: debug
>         [submit_bulk_transfer]
>                  need 4
>                       urbs for new
>                       transfer with length 65536
>                       [ 6.981000] [00001fa4] libusbx: debug
>                  [linux_netlink_read_message] netlink
>                       hotplug found device busnum: 2, devaddr: 57,
>         sys_name: 2-1.4,
>                  removed: yes
>                       [ 6.981000] [00001fa4] libusbx: debug
>                  [linux_device_disconnected] starting
>                       device disconnect...
>                       [ 6.981000] [00001fa4] libusbx: debug
>                  [linux_device_disconnected] lock
>                       acquired...
>                       [ 6.981000] [00001fa4] libusbx: debug
>         [linux_device_disconnected]
>                       getting device
>                       by session... 0x884cdf0
>                       [ 6.981000] [00001fa4] libusbx: debug
>                  [linux_device_disconnected] device:
>                       0x884f0b8
>
>                       I don't know exactly how to proceed here - any hint
>         would be
>                  appreciated.
>
>                       Best regards,
>
>                       Erik
>
>
>
>         ------------------------------____----------------------------__--__------------------
>                       Android apps run on BlackBerry 10
>                       Introducing the new BlackBerry 10.2.1 Runtime for
>         Android apps.
>                       Now with support for Jelly Bean, Bluetooth, Mapview
>         and more.
>                       Get your Android app in front of a whole new
>         audience.  Start now.
>         http://pubads.g.doubleclick.____net/gampad/clk?id=124407151&____iu=/4140/ostg.clktrk
>
>         <http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&__iu=/4140/ostg.clktrk
>         <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk>>
>                       ___________________________________________________
>                       libusbx-devel mailing list
>                  [hidden email]
>         <http://sourceforge.net>
>                  <mailto:[hidden email]>
>                       <mailto:[hidden email]
>         <http://sourceforge.net>
>                  <mailto:[hidden email]>>
>         https://lists.sourceforge.net/____lists/listinfo/libusbx-devel
>         <https://lists.sourceforge.net/__lists/listinfo/libusbx-devel>
>
>         <https://lists.sourceforge.__net/lists/listinfo/libusbx-__devel
>         <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>>
>
>
>
>
>


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Chris Dickens
Hi Erik,

It would be helpful to see when in the course of execution calls to libusb_unref_device() are made. Could you add this, in libusb_unref_device() in core.c:

  usbi_mutex_lock(&dev->lock);
  refcnt = --dev->refcnt;
  usbi_mutex_unlock(&dev->lock);

+  usbi_dbg("unref device %p refcount=%d", dev, recfnt);

Thanks,
Chris




On Fri, Feb 14, 2014 at 9:24 AM, Erik Rull <[hidden email]> wrote:
Hi Chris,

thanks. I compiled it myself, the download is from here:
<http://sourceforge.net/projects/libusbx/files/releases/1.0.17/source/>
Maybe this is wrong, too?

What do you mean with linking to an older version at runtime? I don't have another libusb-x.so.y on the target system so it's very unlikely that the wrong file is selected. Additionally, I added some more debug output and this is visible which lets me assume that the correct library was taken.

At compile time I explicitly add the path to the self compiled version, so the libary should be taken. If I manually delete the .so file and try to link my application, it fails. So the path at compile / link time should be correct, too.
strace shows it:
[pid 12404] open("/home/erik/libusbx/.install/include/libusb-1.0", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
=> this is my selfcompiled version
and ldd points also to the correct version (different path due to my target system) - but the library pointing to it is a copy of the lib linked against above:
libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb70ba000)

Any further ideas?

Best regards,

Erik

Chris Dickens wrote:
Hi Erik,

Sourceforge seems to not have anything past 1.0.12. You can see the commit
on GitHub here
(https://github.com/libusbx/libusbx/commit/858b794cf10ff1ac76a4f453bed7645aa9709c44).
However 1.0.17 does indeed have this problem fixed.

Is 1.0.17 installed as a system package, or did you compile it yourself?
I'm wondering if you are possibly linking to an older version at runtime.

Regards,
Chris

On Friday, February 14, 2014, Erik Rull <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Chris,

    I'm using 1.0.17, the commit cannot be found on the git browser when
    taking your ID, so I can't tell you if I have a too old version.
    <http://libusbx.git.__sourceforge.net/git/gitweb.__cgi?p=libusbx/libusbx;a=__commit;h=__858b794cf10ff1ac76a4f453bed764__5aa9709c44

    <http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44>>

    Would be nice if you could point me to the commit, thanks.

    Best regards,

    Erik


    Chris Dickens wrote:

        Which version of libusb(x) are you using? This sounds like an issue
        that
        was present in an older version (fixed by commit
        858b794cf10ff1ac76a4f453bed764__5aa9709c44).


        Chris


        On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <[hidden email]
        <mailto:[hidden email]>> wrote:

             Hi Chris,

             thanks for your interesting explanation.

             No, I haven't registered any callbacks. I'm using the connect
        to an
             interface and doing bulk reads and bulk writes - no async
        handling. I
             would expect to get a libusb return code that tells me "hey
        the device
             is no longer there" on which I could react safely - and not
        getting a SEGV.

             If I add a usleep(1000) as the first line in the discard-urb
        routines
             everything goes fine - no SEGV.

             Best regards,

             Erik


             Chris Dickens wrote:

                 This line tells a lot of the story:

                 [ 6.849000] [00001fae] libusbx: debug
        [libusb_unref_device] destroy
                 device 2.57

                 This can only happen when a device's refcount == 0, which
        should
                 not happen
                 while an active transfer is occurring. When a device is
        enumerated, its
                 refcount is 1. When you open the device, its refcount is
                 incremented. When
                 you submit a transfer for a device, its refcount is
        incremented. So
                 in the
                 most simplistic case, a device's refcount is 3 while it is
                 connected and a
                 transfer is being processed. If a transfer is in process
        and the
                 device is
                 disconnected before the transfer is finished, its refcount
        will be
                 decremented, so in the simplistic case it would now be 2.
        When the
                 transfer
                 finishes, its refcount will be decremented and should be
        1, leaving the
                 destruction of the device to happen when you close the
        device. The fact
                 that it is being destroyed in
        usbi_handle_transfer_____completion

                 means that
                 the device had to have been unrefed or closed elsewhere,
        and it
                 looks like
                 you may be using it again afterwards.

                 Do you have a hotplug callback registered? If so, what
        does it do
                 with the
                 device upon connection and disconnection?

                 Chris


                 On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull
        <[hidden email]
                 <mailto:[hidden email]>
                 <mailto:[hidden email]__de
                 <mailto:[hidden email]>>> wrote:

                      Hi all,

                      during the debug for the unplug issue reported, I
        encounter
                 now SIGSEGVs on
                      other places:

                      I added some debug output to the libusb/io.c:

                      int usbi_handle_transfer_____completion(struct

        usbi_transfer
                 *itransfer,
                               enum libusb_transfer_status status)
                      {
                               struct libusb_transfer *transfer =

        USBI_TRANSFER_TO_LIBUSB_____TRANSFER(itransfer);

                               struct libusb_context *ctx =
        TRANSFER_CTX(transfer);
                               struct libusb_device_handle *handle =
                 transfer->dev_handle;
                               uint8_t flags;
                               int r = 0;
                               usbi_dbg("entered... %p",ctx);

                               /* FIXME: could be more intelligent with the
        timerfd
                 here. we
                      don't need
                                * to disarm the timerfd if there was no timer
                 running, and we
                      only need
                                * to rearm the timerfd if the transfer that
        expired
                 was the
                      one with
                                * the shortest timeout. */


        usbi_mutex_lock(&ctx->flying_____transfers_lock);
                               usbi_dbg("locked mutex %p
                 %p",itransfer,&itransfer->____list);
                               usbi_dbg("list pointers %p
                      %p",itransfer->list.next,____itransfer->list.prev);

                               list_del(&itransfer->list);
                               usbi_dbg("deleted list");

                      The corresponding output when removing the device is:

                      [ 6.973000] [00001d59] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      entered... 0x884cdf0
                      [ 6.973000] [00001d59] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      locked
                      mutex 0x8813eb8 0x8813ebc
                      [ 6.973000] [00001d59] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      list
                      pointers (nil) (nil)
                      Caught a signal (11: SIGSEGV)

                      This can be easily explained because the list_del
        looks like this:

                      static inline void list_del(struct list_head *entry)
                      {
                               entry->next->prev = entry->prev;
                               entry->prev->next = entry->next;
                               entry->next = entry->prev = NULL;
                      }

                      => entry->next and entry->prev are already NULL! So this
                 delete should
                      never be
                      done, adding some checkings would be helpful.

                      But when adding a check against NULL for each prev
        and next in
                 the list_del
                      before accessing them, the process does not die but
        stalls on
                 another
                      point when
                      trying to do a bulk read the device after connecting:

                      /lib/libusb-1.0.so.0:libusb_____ref_device()
                      /lib/libusb-1.0.so.0:libusb_____submit_transfer()


                      and the last libusb debug output lines are:

                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      entered... 0x884cdf0
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      locked
                      mutex 0x8813eb8 0x8813ebc
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      list
                      pointers (nil) (nil)
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      deleted
                      list
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      transfer
                      0x8813eec has callback 0xb708b0c0
                      [ 6.849000] [00001fae] libusbx: debug [sync_transfer_cb]
                 actual_length=0
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      part 3
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      part 4
                      [ 6.849000] [00001fae] libusbx: debug
        [libusb_unref_device]
                 destroy
                      device 2.57
                      [ 6.849000] [00001fae] libusbx: debug
                 [usbi_handle_transfer_____completion]

                      part 5
                      [ 6.849000] [00001fae] libusbx: debug
        [op_handle_events] Reap for
                      handle done!
                      0x884cf40
                      [ 6.849000] [00001fae] libusbx: debug
        [op_handle_events] Reap for
                      handle done!
                      0x884cf40
                      [ 6.855000] [00001fae] libusbx: debug
        [submit_bulk_transfer]
                 need 4
                      urbs for new
                      transfer with length 65536
                      [ 6.981000] [00001fa4] libusbx: debug
                 [linux_netlink_read_message] netlink
                      hotplug found device busnum: 2, devaddr: 57,
        sys_name: 2-1.4,
                 removed: yes
                      [ 6.981000] [00001fa4] libusbx: debug
                 [linux_device_disconnected] starting
                      device disconnect...
                      [ 6.981000] [00001fa4] libusbx: debug
                 [linux_device_disconnected] lock
                      acquired...
                      [ 6.981000] [00001fa4] libusbx: debug
        [linux_device_disconnected]
                      getting device
                      by session... 0x884cdf0
                      [ 6.981000] [00001fa4] libusbx: debug
                 [linux_device_disconnected] device:
                      0x884f0b8

                      I don't know exactly how to proceed here - any hint
        would be
                 appreciated.

                      Best regards,

                      Erik



        ------------------------------____----------------------------__--__------------------

                      Android apps run on BlackBerry 10
                      Introducing the new BlackBerry 10.2.1 Runtime for
        Android apps.
                      Now with support for Jelly Bean, Bluetooth, Mapview
        and more.
                      Get your Android app in front of a whole new
        audience.  Start now.
        http://pubads.g.doubleclick.____net/gampad/clk?id=124407151&____iu=/4140/ostg.clktrk

        <http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&__iu=/4140/ostg.clktrk
        <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk>>
                      ___________________________________________________
                      libusbx-devel mailing list
                 libusbx-devel@lists.__sourcefo__rge.net
        <http://sourceforge.net>
                 <mailto:[hidden email]>
                      <mailto:[hidden email]__sourceforge.net
        <http://sourceforge.net>
                 <mailto:[hidden email]>>
        https://lists.sourceforge.net/____lists/listinfo/libusbx-devel
        <https://lists.sourceforge.net/__lists/listinfo/libusbx-devel>

        <https://lists.sourceforge.__net/lists/listinfo/libusbx-__devel
        <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>>








------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
Hi Chis,

it's horrible, now the "other" error with the infinite loop comes up again.
Attached my logfile. I'm sorry, but the refcnt seems to be "fine" currently. At
this point I'm running again into the trouble with the issue that the urbs are
NULL and the pointer computation goes wrong and causes a nearly "infinite" loop
(see my emails to this topic). I don't understand why the errors are not
reproducible...
Well - reproducible a bit - I either get this or the other error with the segv -
others I didn't see up to now.

Any further ideas?

Thanks a lot for your help!

Best regards,

Erik


> On February 14, 2014 at 7:21 PM Chris Dickens
> <[hidden email]> wrote:
>
>
> Hi Erik,
>
> It would be helpful to see when in the course of execution calls to
> libusb_unref_device() are made. Could you add this, in
> libusb_unref_device() in core.c:
>
>   usbi_mutex_lock(&dev->lock);
>   refcnt = --dev->refcnt;
>   usbi_mutex_unlock(&dev->lock);
>
> +  usbi_dbg("unref device %p refcount=%d", dev, recfnt);
>
> Thanks,
> Chris
>
>
>
>
> On Fri, Feb 14, 2014 at 9:24 AM, Erik Rull <[hidden email]> wrote:
>
> > Hi Chris,
> >
> > thanks. I compiled it myself, the download is from here:
> > <http://sourceforge.net/projects/libusbx/files/releases/1.0.17/source/>
> > Maybe this is wrong, too?
> >
> > What do you mean with linking to an older version at runtime? I don't have
> > another libusb-x.so.y on the target system so it's very unlikely that the
> > wrong file is selected. Additionally, I added some more debug output and
> > this is visible which lets me assume that the correct library was taken.
> >
> > At compile time I explicitly add the path to the self compiled version, so
> > the libary should be taken. If I manually delete the .so file and try to
> > link my application, it fails. So the path at compile / link time should be
> > correct, too.
> > strace shows it:
> > [pid 12404] open("/home/erik/libusbx/.install/include/libusb-1.0",
> > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> > => this is my selfcompiled version
> > and ldd points also to the correct version (different path due to my
> > target system) - but the library pointing to it is a copy of the lib linked
> > against above:
> > libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb70ba000)
> >
> > Any further ideas?
> >
> > Best regards,
> >
> > Erik
> >
> > Chris Dickens wrote:
> >
> >> Hi Erik,
> >>
> >> Sourceforge seems to not have anything past 1.0.12. You can see the commit
> >> on GitHub here
> >> (https://github.com/libusbx/libusbx/commit/858b794cf10ff1ac76a4f453bed764
> >> 5aa9709c44).
> >> However 1.0.17 does indeed have this problem fixed.
> >>
> >> Is 1.0.17 installed as a system package, or did you compile it yourself?
> >> I'm wondering if you are possibly linking to an older version at runtime.
> >>
> >> Regards,
> >> Chris
> >>
> >> On Friday, February 14, 2014, Erik Rull <[hidden email]
> >> <mailto:[hidden email]>> wrote:
> >>
> >>     Hi Chris,
> >>
> >>     I'm using 1.0.17, the commit cannot be found on the git browser when
> >>     taking your ID, so I can't tell you if I have a too old version.
> >>     <http://libusbx.git.__sourceforge.net/git/gitweb.__cgi?p=
> >> libusbx/libusbx;a=__commit;h=__858b794cf10ff1ac76a4f453bed764__5aa9709c44
> >>
> >>     <http://libusbx.git.sourceforge.net/git/gitweb.
> >> cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44
> >> >>
> >>
> >>     Would be nice if you could point me to the commit, thanks.
> >>
> >>     Best regards,
> >>
> >>     Erik
> >>
> >>
> >>     Chris Dickens wrote:
> >>
> >>         Which version of libusb(x) are you using? This sounds like an
> >> issue
> >>         that
> >>         was present in an older version (fixed by commit
> >>         858b794cf10ff1ac76a4f453bed764__5aa9709c44).
> >>
> >>
> >>         Chris
> >>
> >>
> >>         On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <
> >> [hidden email]
> >>         <mailto:[hidden email]>> wrote:
> >>
> >>              Hi Chris,
> >>
> >>              thanks for your interesting explanation.
> >>
> >>              No, I haven't registered any callbacks. I'm using the connect
> >>         to an
> >>              interface and doing bulk reads and bulk writes - no async
> >>         handling. I
> >>              would expect to get a libusb return code that tells me "hey
> >>         the device
> >>              is no longer there" on which I could react safely - and not
> >>         getting a SEGV.
> >>
> >>              If I add a usleep(1000) as the first line in the discard-urb
> >>         routines
> >>              everything goes fine - no SEGV.
> >>
> >>              Best regards,
> >>
> >>              Erik
> >>
> >>
> >>              Chris Dickens wrote:
> >>
> >>                  This line tells a lot of the story:
> >>
> >>                  [ 6.849000] [00001fae] libusbx: debug
> >>         [libusb_unref_device] destroy
> >>                  device 2.57
> >>
> >>                  This can only happen when a device's refcount == 0, which
> >>         should
> >>                  not happen
> >>                  while an active transfer is occurring. When a device is
> >>         enumerated, its
> >>                  refcount is 1. When you open the device, its refcount is
> >>                  incremented. When
> >>                  you submit a transfer for a device, its refcount is
> >>         incremented. So
> >>                  in the
> >>                  most simplistic case, a device's refcount is 3 while it
> >> is
> >>                  connected and a
> >>                  transfer is being processed. If a transfer is in process
> >>         and the
> >>                  device is
> >>                  disconnected before the transfer is finished, its
> >> refcount
> >>         will be
> >>                  decremented, so in the simplistic case it would now be 2.
> >>         When the
> >>                  transfer
> >>                  finishes, its refcount will be decremented and should be
> >>         1, leaving the
> >>                  destruction of the device to happen when you close the
> >>         device. The fact
> >>                  that it is being destroyed in
> >>         usbi_handle_transfer_____completion
> >>
> >>                  means that
> >>                  the device had to have been unrefed or closed elsewhere,
> >>         and it
> >>                  looks like
> >>                  you may be using it again afterwards.
> >>
> >>                  Do you have a hotplug callback registered? If so, what
> >>         does it do
> >>                  with the
> >>                  device upon connection and disconnection?
> >>
> >>                  Chris
> >>
> >>
> >>                  On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull
> >>         <[hidden email]
> >>                  <mailto:[hidden email]>
> >>                  <mailto:erik.rull@rdsoftware.__de
> >>                  <mailto:[hidden email]>>> wrote:
> >>
> >>                       Hi all,
> >>
> >>                       during the debug for the unplug issue reported, I
> >>         encounter
> >>                  now SIGSEGVs on
> >>                       other places:
> >>
> >>                       I added some debug output to the libusb/io.c:
> >>
> >>                       int usbi_handle_transfer_____completion(struct
> >>
> >>         usbi_transfer
> >>                  *itransfer,
> >>                                enum libusb_transfer_status status)
> >>                       {
> >>                                struct libusb_transfer *transfer =
> >>
> >>         USBI_TRANSFER_TO_LIBUSB_____TRANSFER(itransfer);
> >>
> >>                                struct libusb_context *ctx =
> >>         TRANSFER_CTX(transfer);
> >>                                struct libusb_device_handle *handle =
> >>                  transfer->dev_handle;
> >>                                uint8_t flags;
> >>                                int r = 0;
> >>                                usbi_dbg("entered... %p",ctx);
> >>
> >>                                /* FIXME: could be more intelligent with
> >> the
> >>         timerfd
> >>                  here. we
> >>                       don't need
> >>                                 * to disarm the timerfd if there was no
> >> timer
> >>                  running, and we
> >>                       only need
> >>                                 * to rearm the timerfd if the transfer
> >> that
> >>         expired
> >>                  was the
> >>                       one with
> >>                                 * the shortest timeout. */
> >>
> >>
> >>         usbi_mutex_lock(&ctx->flying_____transfers_lock);
> >>                                usbi_dbg("locked mutex %p
> >>                  %p",itransfer,&itransfer->____list);
> >>                                usbi_dbg("list pointers %p
> >>                       %p",itransfer->list.next,____itransfer->list.prev);
> >>
> >>                                list_del(&itransfer->list);
> >>                                usbi_dbg("deleted list");
> >>
> >>                       The corresponding output when removing the device
> >> is:
> >>
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       entered... 0x884cdf0
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       locked
> >>                       mutex 0x8813eb8 0x8813ebc
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       list
> >>                       pointers (nil) (nil)
> >>                       Caught a signal (11: SIGSEGV)
> >>
> >>                       This can be easily explained because the list_del
> >>         looks like this:
> >>
> >>                       static inline void list_del(struct list_head *entry)
> >>                       {
> >>                                entry->next->prev = entry->prev;
> >>                                entry->prev->next = entry->next;
> >>                                entry->next = entry->prev = NULL;
> >>                       }
> >>
> >>                       => entry->next and entry->prev are already NULL! So
> >> this
> >>                  delete should
> >>                       never be
> >>                       done, adding some checkings would be helpful.
> >>
> >>                       But when adding a check against NULL for each prev
> >>         and next in
> >>                  the list_del
> >>                       before accessing them, the process does not die but
> >>         stalls on
> >>                  another
> >>                       point when
> >>                       trying to do a bulk read the device after
> >> connecting:
> >>
> >>                       /lib/libusb-1.0.so.0:libusb_____ref_device()
> >>                       /lib/libusb-1.0.so.0:libusb_____submit_transfer()
> >>
> >>
> >>                       and the last libusb debug output lines are:
> >>
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       entered... 0x884cdf0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       locked
> >>                       mutex 0x8813eb8 0x8813ebc
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       list
> >>                       pointers (nil) (nil)
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       deleted
> >>                       list
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       transfer
> >>                       0x8813eec has callback 0xb708b0c0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >> [sync_transfer_cb]
> >>                  actual_length=0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 3
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 4
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [libusb_unref_device]
> >>                  destroy
> >>                       device 2.57
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 5
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [op_handle_events] Reap for
> >>                       handle done!
> >>                       0x884cf40
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [op_handle_events] Reap for
> >>                       handle done!
> >>                       0x884cf40
> >>                       [ 6.855000] [00001fae] libusbx: debug
> >>         [submit_bulk_transfer]
> >>                  need 4
> >>                       urbs for new
> >>                       transfer with length 65536
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_netlink_read_message] netlink
> >>                       hotplug found device busnum: 2, devaddr: 57,
> >>         sys_name: 2-1.4,
> >>                  removed: yes
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] starting
> >>                       device disconnect...
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] lock
> >>                       acquired...
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>         [linux_device_disconnected]
> >>                       getting device
> >>                       by session... 0x884cdf0
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] device:
> >>                       0x884f0b8
> >>
> >>                       I don't know exactly how to proceed here - any hint
> >>         would be
> >>                  appreciated.
> >>
> >>                       Best regards,
> >>
> >>                       Erik
> >>
> >>
> >>
> >>         ------------------------------____--------------------------
> >> --__--__------------------
> >>
> >>                       Android apps run on BlackBerry 10
> >>                       Introducing the new BlackBerry 10.2.1 Runtime for
> >>         Android apps.
> >>                       Now with support for Jelly Bean, Bluetooth, Mapview
> >>         and more.
> >>                       Get your Android app in front of a whole new
> >>         audience.  Start now.
> >>         http://pubads.g.doubleclick.____net/gampad/clk?id=124407151&
> >> ____iu=/4140/ostg.clktrk
> >>
> >>         <http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&_
> >> _iu=/4140/ostg.clktrk
> >>         <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&
> >> iu=/4140/ostg.clktrk>>
> >>                       ___________________________________________________
> >>                       libusbx-devel mailing list
> >>                  [hidden email]
> >>         <http://sourceforge.net>
> >>                  <mailto:[hidden email]>
> >>                       <mailto:[hidden email]
> >>         <http://sourceforge.net>
> >>                  <mailto:[hidden email]>>
> >>         https://lists.sourceforge.net/____lists/listinfo/libusbx-devel
> >>         <https://lists.sourceforge.net/__lists/listinfo/libusbx-devel>
> >>
> >>         <https://lists.sourceforge.__net/lists/listinfo/libusbx-__devel
> >>         <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

libusb-loop.txt (106K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

Erik Rull
In reply to this post by Chris Dickens
Hi Chris,

I got it again - attached the logfile with the SEGV - but the last refcount was
2 - and there was not yet a device disconnect detected... During the
SEGV-Handler I see a line like:
[ 6.679000] [00002d88] libusbx: debug [linux_netlink_read_message] netlink
hotplug found device busnum: 2, devaddr: 80, sys_name: 2-1.4, removed: yes

Maybe you see more than I can detect?

Best regards,

Erik



> On February 14, 2014 at 7:21 PM Chris Dickens
> <[hidden email]> wrote:
>
>
> Hi Erik,
>
> It would be helpful to see when in the course of execution calls to
> libusb_unref_device() are made. Could you add this, in
> libusb_unref_device() in core.c:
>
>   usbi_mutex_lock(&dev->lock);
>   refcnt = --dev->refcnt;
>   usbi_mutex_unlock(&dev->lock);
>
> +  usbi_dbg("unref device %p refcount=%d", dev, recfnt);
>
> Thanks,
> Chris
>
>
>
>
> On Fri, Feb 14, 2014 at 9:24 AM, Erik Rull <[hidden email]> wrote:
>
> > Hi Chris,
> >
> > thanks. I compiled it myself, the download is from here:
> > <http://sourceforge.net/projects/libusbx/files/releases/1.0.17/source/>
> > Maybe this is wrong, too?
> >
> > What do you mean with linking to an older version at runtime? I don't have
> > another libusb-x.so.y on the target system so it's very unlikely that the
> > wrong file is selected. Additionally, I added some more debug output and
> > this is visible which lets me assume that the correct library was taken.
> >
> > At compile time I explicitly add the path to the self compiled version, so
> > the libary should be taken. If I manually delete the .so file and try to
> > link my application, it fails. So the path at compile / link time should be
> > correct, too.
> > strace shows it:
> > [pid 12404] open("/home/erik/libusbx/.install/include/libusb-1.0",
> > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> > => this is my selfcompiled version
> > and ldd points also to the correct version (different path due to my
> > target system) - but the library pointing to it is a copy of the lib linked
> > against above:
> > libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb70ba000)
> >
> > Any further ideas?
> >
> > Best regards,
> >
> > Erik
> >
> > Chris Dickens wrote:
> >
> >> Hi Erik,
> >>
> >> Sourceforge seems to not have anything past 1.0.12. You can see the commit
> >> on GitHub here
> >> (https://github.com/libusbx/libusbx/commit/858b794cf10ff1ac76a4f453bed764
> >> 5aa9709c44).
> >> However 1.0.17 does indeed have this problem fixed.
> >>
> >> Is 1.0.17 installed as a system package, or did you compile it yourself?
> >> I'm wondering if you are possibly linking to an older version at runtime.
> >>
> >> Regards,
> >> Chris
> >>
> >> On Friday, February 14, 2014, Erik Rull <[hidden email]
> >> <mailto:[hidden email]>> wrote:
> >>
> >>     Hi Chris,
> >>
> >>     I'm using 1.0.17, the commit cannot be found on the git browser when
> >>     taking your ID, so I can't tell you if I have a too old version.
> >>     <http://libusbx.git.__sourceforge.net/git/gitweb.__cgi?p=
> >> libusbx/libusbx;a=__commit;h=__858b794cf10ff1ac76a4f453bed764__5aa9709c44
> >>
> >>     <http://libusbx.git.sourceforge.net/git/gitweb.
> >> cgi?p=libusbx/libusbx;a=commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44
> >> >>
> >>
> >>     Would be nice if you could point me to the commit, thanks.
> >>
> >>     Best regards,
> >>
> >>     Erik
> >>
> >>
> >>     Chris Dickens wrote:
> >>
> >>         Which version of libusb(x) are you using? This sounds like an
> >> issue
> >>         that
> >>         was present in an older version (fixed by commit
> >>         858b794cf10ff1ac76a4f453bed764__5aa9709c44).
> >>
> >>
> >>         Chris
> >>
> >>
> >>         On Thu, Feb 13, 2014 at 2:29 PM, Erik Rull <
> >> [hidden email]
> >>         <mailto:[hidden email]>> wrote:
> >>
> >>              Hi Chris,
> >>
> >>              thanks for your interesting explanation.
> >>
> >>              No, I haven't registered any callbacks. I'm using the connect
> >>         to an
> >>              interface and doing bulk reads and bulk writes - no async
> >>         handling. I
> >>              would expect to get a libusb return code that tells me "hey
> >>         the device
> >>              is no longer there" on which I could react safely - and not
> >>         getting a SEGV.
> >>
> >>              If I add a usleep(1000) as the first line in the discard-urb
> >>         routines
> >>              everything goes fine - no SEGV.
> >>
> >>              Best regards,
> >>
> >>              Erik
> >>
> >>
> >>              Chris Dickens wrote:
> >>
> >>                  This line tells a lot of the story:
> >>
> >>                  [ 6.849000] [00001fae] libusbx: debug
> >>         [libusb_unref_device] destroy
> >>                  device 2.57
> >>
> >>                  This can only happen when a device's refcount == 0, which
> >>         should
> >>                  not happen
> >>                  while an active transfer is occurring. When a device is
> >>         enumerated, its
> >>                  refcount is 1. When you open the device, its refcount is
> >>                  incremented. When
> >>                  you submit a transfer for a device, its refcount is
> >>         incremented. So
> >>                  in the
> >>                  most simplistic case, a device's refcount is 3 while it
> >> is
> >>                  connected and a
> >>                  transfer is being processed. If a transfer is in process
> >>         and the
> >>                  device is
> >>                  disconnected before the transfer is finished, its
> >> refcount
> >>         will be
> >>                  decremented, so in the simplistic case it would now be 2.
> >>         When the
> >>                  transfer
> >>                  finishes, its refcount will be decremented and should be
> >>         1, leaving the
> >>                  destruction of the device to happen when you close the
> >>         device. The fact
> >>                  that it is being destroyed in
> >>         usbi_handle_transfer_____completion
> >>
> >>                  means that
> >>                  the device had to have been unrefed or closed elsewhere,
> >>         and it
> >>                  looks like
> >>                  you may be using it again afterwards.
> >>
> >>                  Do you have a hotplug callback registered? If so, what
> >>         does it do
> >>                  with the
> >>                  device upon connection and disconnection?
> >>
> >>                  Chris
> >>
> >>
> >>                  On Thu, Feb 13, 2014 at 3:41 AM, Erik Rull
> >>         <[hidden email]
> >>                  <mailto:[hidden email]>
> >>                  <mailto:erik.rull@rdsoftware.__de
> >>                  <mailto:[hidden email]>>> wrote:
> >>
> >>                       Hi all,
> >>
> >>                       during the debug for the unplug issue reported, I
> >>         encounter
> >>                  now SIGSEGVs on
> >>                       other places:
> >>
> >>                       I added some debug output to the libusb/io.c:
> >>
> >>                       int usbi_handle_transfer_____completion(struct
> >>
> >>         usbi_transfer
> >>                  *itransfer,
> >>                                enum libusb_transfer_status status)
> >>                       {
> >>                                struct libusb_transfer *transfer =
> >>
> >>         USBI_TRANSFER_TO_LIBUSB_____TRANSFER(itransfer);
> >>
> >>                                struct libusb_context *ctx =
> >>         TRANSFER_CTX(transfer);
> >>                                struct libusb_device_handle *handle =
> >>                  transfer->dev_handle;
> >>                                uint8_t flags;
> >>                                int r = 0;
> >>                                usbi_dbg("entered... %p",ctx);
> >>
> >>                                /* FIXME: could be more intelligent with
> >> the
> >>         timerfd
> >>                  here. we
> >>                       don't need
> >>                                 * to disarm the timerfd if there was no
> >> timer
> >>                  running, and we
> >>                       only need
> >>                                 * to rearm the timerfd if the transfer
> >> that
> >>         expired
> >>                  was the
> >>                       one with
> >>                                 * the shortest timeout. */
> >>
> >>
> >>         usbi_mutex_lock(&ctx->flying_____transfers_lock);
> >>                                usbi_dbg("locked mutex %p
> >>                  %p",itransfer,&itransfer->____list);
> >>                                usbi_dbg("list pointers %p
> >>                       %p",itransfer->list.next,____itransfer->list.prev);
> >>
> >>                                list_del(&itransfer->list);
> >>                                usbi_dbg("deleted list");
> >>
> >>                       The corresponding output when removing the device
> >> is:
> >>
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       entered... 0x884cdf0
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       locked
> >>                       mutex 0x8813eb8 0x8813ebc
> >>                       [ 6.973000] [00001d59] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       list
> >>                       pointers (nil) (nil)
> >>                       Caught a signal (11: SIGSEGV)
> >>
> >>                       This can be easily explained because the list_del
> >>         looks like this:
> >>
> >>                       static inline void list_del(struct list_head *entry)
> >>                       {
> >>                                entry->next->prev = entry->prev;
> >>                                entry->prev->next = entry->next;
> >>                                entry->next = entry->prev = NULL;
> >>                       }
> >>
> >>                       => entry->next and entry->prev are already NULL! So
> >> this
> >>                  delete should
> >>                       never be
> >>                       done, adding some checkings would be helpful.
> >>
> >>                       But when adding a check against NULL for each prev
> >>         and next in
> >>                  the list_del
> >>                       before accessing them, the process does not die but
> >>         stalls on
> >>                  another
> >>                       point when
> >>                       trying to do a bulk read the device after
> >> connecting:
> >>
> >>                       /lib/libusb-1.0.so.0:libusb_____ref_device()
> >>                       /lib/libusb-1.0.so.0:libusb_____submit_transfer()
> >>
> >>
> >>                       and the last libusb debug output lines are:
> >>
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       entered... 0x884cdf0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       locked
> >>                       mutex 0x8813eb8 0x8813ebc
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       list
> >>                       pointers (nil) (nil)
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       deleted
> >>                       list
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       transfer
> >>                       0x8813eec has callback 0xb708b0c0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >> [sync_transfer_cb]
> >>                  actual_length=0
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 3
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 4
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [libusb_unref_device]
> >>                  destroy
> >>                       device 2.57
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>                  [usbi_handle_transfer_____completion]
> >>
> >>                       part 5
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [op_handle_events] Reap for
> >>                       handle done!
> >>                       0x884cf40
> >>                       [ 6.849000] [00001fae] libusbx: debug
> >>         [op_handle_events] Reap for
> >>                       handle done!
> >>                       0x884cf40
> >>                       [ 6.855000] [00001fae] libusbx: debug
> >>         [submit_bulk_transfer]
> >>                  need 4
> >>                       urbs for new
> >>                       transfer with length 65536
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_netlink_read_message] netlink
> >>                       hotplug found device busnum: 2, devaddr: 57,
> >>         sys_name: 2-1.4,
> >>                  removed: yes
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] starting
> >>                       device disconnect...
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] lock
> >>                       acquired...
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>         [linux_device_disconnected]
> >>                       getting device
> >>                       by session... 0x884cdf0
> >>                       [ 6.981000] [00001fa4] libusbx: debug
> >>                  [linux_device_disconnected] device:
> >>                       0x884f0b8
> >>
> >>                       I don't know exactly how to proceed here - any hint
> >>         would be
> >>                  appreciated.
> >>
> >>                       Best regards,
> >>
> >>                       Erik
> >>
> >>
> >>
> >>         ------------------------------____--------------------------
> >> --__--__------------------
> >>
> >>                       Android apps run on BlackBerry 10
> >>                       Introducing the new BlackBerry 10.2.1 Runtime for
> >>         Android apps.
> >>                       Now with support for Jelly Bean, Bluetooth, Mapview
> >>         and more.
> >>                       Get your Android app in front of a whole new
> >>         audience.  Start now.
> >>         http://pubads.g.doubleclick.____net/gampad/clk?id=124407151&
> >> ____iu=/4140/ostg.clktrk
> >>
> >>         <http://pubads.g.doubleclick.__net/gampad/clk?id=124407151&_
> >> _iu=/4140/ostg.clktrk
> >>         <http://pubads.g.doubleclick.net/gampad/clk?id=124407151&
> >> iu=/4140/ostg.clktrk>>
> >>                       ___________________________________________________
> >>                       libusbx-devel mailing list
> >>                  [hidden email]
> >>         <http://sourceforge.net>
> >>                  <mailto:[hidden email]>
> >>                       <mailto:[hidden email]
> >>         <http://sourceforge.net>
> >>                  <mailto:[hidden email]>>
> >>         https://lists.sourceforge.net/____lists/listinfo/libusbx-devel
> >>         <https://lists.sourceforge.net/__lists/listinfo/libusbx-devel>
> >>
> >>         <https://lists.sourceforge.__net/lists/listinfo/libusbx-__devel
> >>         <https://lists.sourceforge.net/lists/listinfo/libusbx-devel>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

libusb-segv.txt (42K) Download Attachment
Loading...