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 <erik.r...@rdsoftware.de
> <mailto:erik.r...@rdsoftware.de>> 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 <erik.r...@rdsoftware.de
> <mailto:erik.r...@rdsoftware.de>> 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
> <erik.r...@rdsoftware.de
> <mailto:erik.r...@rdsoftware.de>
> <mailto:erik.rull@rdsoftware.__de
> <mailto:erik.r...@rdsoftware.de>>> 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:libusbx-devel@lists.sourceforge.net>
> <mailto:libusbx-devel@lists.__sourceforge.net
> <http://sourceforge.net>
> <mailto:libusbx-devel@lists.sourceforge.net>>
> 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
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
