Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
Good morning Pete, Ludovic and Orin,
yesterday, I recompiled the latest libusbx version from the git
repository with debug information (version 1.0.12.10545) and replaced
it on the computers.
> On 2012.08.03 15:51, Pete Batard wrote:
> If you do observe the crash again, and since you're recompiling the
> library, I would also advise you to try changing line 1307 in
> libusb/io.c from:
>
> if (r) {
>
> to
> if (r && (r != LIBUSB_ERROR_BUSY)) {
I applied the suggested code change as well.
Please see the attached file with a new backtrace of the segmentation
fault. The file contains all of the commands you told me to execute
last week.
If you need anything else, please let me know.
=
Regards
Sebastian
=
Syslog
==
Aug 7 03:26:18 kernel: [186531.500116] pcscd[26721]: segfault at 8 ip 00c1fe89
sp b6fd1ff0 error 4 in libusb-1.0.so.0.1.0[c1a000+11000]
gdb /usr/sbin/pcscd core
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
On 2012.08.07 08:30, sebasti...@gmx-topmail.de wrote:
Please see the attached file with a new backtrace of the segmentation
fault. The file contains all of the commands you told me to execute
last week.
Thanks for the report.
Did you get the impression that crash happened sooner than the previous
ones this time around, or what is about the same?
Of course, since we haven't fixed anything at this stage, the backtrace
analysis shows what we already knew, in that we're crashing because
we're trying to add a new element to a transfer list that contains a
single element with its prev/next pointers unexpectedly set to NULL.
Still can't figure out how we can end up with NULL prev/next when we
should have a solid mutex and with list_add calls that should leave
those properly set, so I guess the next step is to add some instrumentation.
Could you try applying the attached patch, that also contains the
potential workaround against double deletion on BUSY that I mentioned
last week, and let us know what happens? You should be able to use "git
apply add-instrumentation-for-next-prev-avoid-transfer-del.patch" to do so.
The patch should log libusbx errors if it detects NULL prev/next, which
will hopefully give us further hints as to what is going on.
Regards,
/Pete
>From d99cc4ef54806d93084c6cdda7ebf3aa2b5a4d0c Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Tue, 7 Aug 2012 11:26:57 +0100
Subject: [PATCH] add instrumentation for next/prev + avoid transfer del on
BUSY
---
libusb/io.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libusb/io.c b/libusb/io.c
index e6d4132..b0da65d 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -1166,12 +1166,16 @@ static int add_to_flying_list(struct usbi_transfer
*transfer)
/* if we have no other flying transfers, start the list with this one */
if (list_empty(&ctx->flying_transfers)) {
list_add(&transfer->list, &ctx->flying_transfers);
+ if ((&transfer->list.next == NULL) || (&transfer->list.prev ==
NULL))
+ usbi_err(ctx, "next/prev is NULL on empty list add");
goto out;
}
/* if we have infinite timeout, append to end of list */
if (!timerisset(timeout)) {
list_add_tail(&transfer->list, &ctx->flying_transfers);
+ if ((&transfer->list.next == NULL) || (&transfer->list.prev ==
NULL))
+ usbi_err(ctx, "next/prev is NULL on infinite timeout
add");
/* first is irrelevant in this case */
goto out;
}
@@ -1185,6 +1189,8 @@ static int add_to_flying_list(struct usbi_transfer
*transfer)
(cur_tv->tv_sec == timeout->tv_sec &&
cur_tv->tv_usec > timeout->tv_usec)) {
list_add_tail(&transfer->list, &cur->list);
+ if ((&transfer->list.next == NULL) ||
(&transfer->list.prev == NULL))
+ usbi_err(ctx, "next/prev is NULL on list add
(middle)");
goto out;
}
first = 0;
@@ -1193,6 +1199,9 @@ static int add_to_flying_list(struct usbi_transfer
*transfer)
/* otherwise we need to be inserted at the end */
list_add_tail(&transfer->list, &ctx->flying_transfers);
+ if ((&transfer->list.next == NULL) || (&transfer->list.prev == NULL))
+ usbi_err(ctx, "next/prev is NULL on list add (end)");
+
out:
#ifdef USBI_TIMERFD_AVAILABLE
if (first && usbi_using_timerfd(ctx) && timerisset(timeout)) {
@@ -1378,7 +1387,7 @@ int API_EXPORTED libusb_submit_transfer(struct
libusb_transfer *transfer)
if (r)
goto out;
r = usbi_backend->submit_transfer(itransfer);
- if (r) {
+ if ((r) && (r != LIBUSB_ERROR_BUSY)) {
usbi_mutex_lock(&ctx->flying_transfers_lock);
list_del(&itransfer->list);
arm_timerfd_for_next_timeout(ctx);
--
1.7.11.msysgit.0
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
> On 2012.08.07 12:44, Pete Batard wrote: > Did you get the impression that crash happened sooner than the previous > ones this time around, or what is about the same? Very hard to say. To me it seems that the failure occurs totally randomly. Sometimes after some hours, sometimes after several days. This time it occured after 13 hours. I tried to apply your patch, but I get the following error: # git apply add-instrumentation-for-next-prev-avoid-transfer-del.patch error: patch failed: libusb/io.c:1166 error: libusb/io.c: patch does not apply # git apply --stat add-instrumentation-for-next-prev-avoid-transfer-del.patch libusb/io.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) # git apply --check add-instrumentation-for-next-prev-avoid-transfer-del.patch error: patch failed: libusb/io.c:1166 error: libusb/io.c: patch does not apply The repository is up-to-date (1.0.12.10545). So I had to apply it manually. I'll distribute the recompiled libusbx today, after some short testing. = Regards Sebastian = -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
On 2012.08.07 13:00, sebasti...@gmx-topmail.de wrote: >> On 2012.08.07 12:44, Pete Batard wrote: >> Did you get the impression that crash happened sooner than the previous >> ones this time around, or what is about the same? > Very hard to say. To me it seems that the failure occurs totally > randomly. Sometimes after some hours, sometimes after several days. > This time it occured after 13 hours. > > I tried to apply your patch, but I get the following error: > # git apply add-instrumentation-for-next-prev-avoid-transfer-del.patch > error: patch failed: libusb/io.c:1166 > error: libusb/io.c: patch does not apply Might be because I generated the patch from a branch that wasn't mainline. io.c should have been the same though. I'll make sure to generate a patch against mainline next time around. > The repository is up-to-date (1.0.12.10545). So I had to apply it manually. > > I'll distribute the recompiled libusbx today, after some short testing. OK. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
Just for information: I got another core dump with the libusbx compiled on monday. Are you interested in this one? Program terminated with signal 11, Segmentation fault. #0 0x00115e89 in add_to_flying_list (transfer=0xb5600468) at io.c:1175 1175io.c: Datei oder Verzeichnis nicht gefunden. in io.c (gdb) backtrace #0 0x00115e89 in add_to_flying_list (transfer=0xb5600468) at io.c:1175 #1 0x00116358 in arm_timerfd_for_next_timeout (ctx=0xb560049c) at io.c:1338 #2 0x001181e8 in libusb_control_transfer (dev_handle=0x965b140, bmRequestType=232 '\350', bRequest=184 '\270', wValue=33011, wIndex=18, data=0x3e8 , wLength=52120, timeout=1232166) at sync.c:148 #3 0x0011836f in do_sync_bulk_transfer (dev_handle=0x965b140, endpoint=38 '&', buffer=0x965cb98 "k\b", length=18, transferred=0xb6f1e13c, timeout=1000, type=2 '\002') at sync.c:190 #4 0x001388a7 in CCIDDevSend (Lun=0, TxBuffer=0x965cb98 "k\b", TxLength=18, ulEscapeSpecificTimeout=1000) at ./bus/usb/usb.c:1055 #5 0x0012cfba in CCIDDevSendWrap (Lun=1387572, request=0x965cb98 "k\b", slot=18) at ccid/common.c:901 #6 0x0012e2a8 in PC_to_RDR_Escape (Lun=0, slot=0x965bbd0, pTxBuffer=0xb6f1e23c "G\003\a?\006?+", dwTxLength=8, pRxBuffer=0xb6f1e1fc "\033\340\034\355\a?\006?+", pdwRxLength=0xb6f1e27c, fIsLocked=0 '\000') at ccid/common.c:3026 #7 0x0014368f in WriteMultipleRegisters (slot=0x965bbd0, ucEnterAction=3 '\003', pbWriteBuffer=0xb6f1e2b6 "\a?\006?+", ulBytesToWrite=6) at ./okccid/rfid/rfid_fw5x.c:85 #8 0x0014379c in RC632ResetTimerUnit (psRFIDReader=0x965bca0) at ./okccid/rfid/rfid_fw5x.c:1436 #9 0x0013f56e in RFIDCardDetectAndTrack (pSlot=0x965bbd0) at ./okccid/rfid/rfid.c:2347 #10 0x00140d30 in RFIDUpdateCurrentStateThread (pSlot=0x965bbd0) at ./okccid/rfid/rfid.c:593 #11 0x00451d31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #12 0x00c8f46e in clone () from /lib/i386-linux-gnu/libc.so.6 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
On 2012.08.07 14:47, sebasti...@gmx-topmail.de wrote: > Just for information: > I got another core dump with the libusbx compiled on monday. > Are you interested in this one? It breaks at the same location, so it will provide the same information as what we already know. Just to confirm, you may want to check that "print *ctx" still shows that the list has a single element (prev = next in flying_transfers) and that "print *(struct usbi_transfer*) " indicates that prev and next are zero for the 'list' attribute. If that is not the case, please let us know. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Windows CE backend and driver
Pete Batard wrote: > Of course it would be quite ironic if intel were the ones who pushed MS > and others to use ia64 in the first place, in order to push brand > recognition (ia = "Intel Architecture"), and got bitten at their own > game when their competitor both followed suit with amd64 and actually > managed to set the course for mainstream 64 bit adoption. Karma's a bitch ain't it? ;) -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] libusb0 & libusbK driver support
All,
If you have some interest with regards to libusb-win32 and libusbK
driver support, you may want to have a look at the new 0K ("zero K")
branch from the pbatard/libusbx repo on github [1].
I have now pushed a patch that adds libusb0.sys and libusbK.sys support
there, for testing.
To fetch the branch:
git clone git://github.com/pbatard/libusbx.git libusbx-pbatard
cd libusbx-pbatard
git checkout 0K
Note that because the branch is not off mainline, but off a personal
libusbx repo, you must go through a new clone.
For testing, you may also want to install the libusb-win32 and libusbK
drivers, in which case you can use the latest Zadig, released today, and
that include support for libusb0.sys v1.2.6.0 & libusbK v3.0.5.16 RC
(Will K 3.0.5 ever go out of RC?).
As usual, Zadig can be downloaded at [2].
For an idea of what the commit entails (patch), have a look at [3].
Basically, if libusbK is installed on the system, we make use of the
WinUSB-like access provided by the K DLL for libusb0, libusbK as well as
WinUSB access, which simplifies things quite a bit. And again, I have to
thank Travis for his effort on providing WinUSB emulation there.
If K is not installed, we just go through the regular WinUSB DLL as usual.
The main major change we had to apply then was the adding of a sub_api
parameters for the bulk of our driver API calls. But apart from that, I
would say that the changes are relatively minimal.
I should also point out that the implementation is very dependent on the
KUSB_FNID definitions from libusbK and their order, which means that
older versions of the K DLL based, that had a different organization for
KUSB_FNID may not work (and potential future breakage is also a
possibility). Maybe we'll try to do something about that is if it
becomes an issue. And while it may have simplified our implementation a
bit, we chose not to use lusbk_dynapi.c for the libusbK distro, mostly
because that would add about 200 KB of source, most of which aren't
really relevant for our use, and also because we wanted to ensure that
WinUSB could still be used as standalone (i.e. outside of libusbK.dll
being present on the system), as it would be an unacceptable regression
for our users otherwise. Plus there's also the issue of lusbk_dynapi.c
not using an LGPL v2.1 compatible license.
As Xiaofan and Travis may remember, we also threw in some vague plan of
trying to merge the K and X libraries in the future, but we'll probably
need to see what comes out of libusbx v2.0 before we look into that...
So far, early tests against the XBox controller as well as an EZ-USB FX2
device appear to indicate that device access is working OK, though I
haven't checked the libusb0.sys as filter driver, and my tests have been
limited.
The one minor issue I found is that I get the following in xusb when
trying to fetch the string descriptors of an XBox Controller device,
when libusb-win32 is used:
Reading string descriptors:
libusbx: error [winusbx_submit_control_transfer] ControlTransfer failed:
[31] A device attached to the system is not functioning.
That device doesn't have strings, so this is not a major issue, and the
libusb0 driver doesn't seem to have an issue returning strings for
devices that have them. It's just in case there are no strings that
libsusb0 seems to differ from the others and produces an error whereas
the other drivers don't complain.
Regards,
/Pete
[1] https://github.com/pbatard/libusbx/tree/0K
[2] https://sourceforge.net/projects/libwdi/files/zadig/
[3]
https://github.com/pbatard/libusbx/commit/8ab3fc618ba90bb14686dcadd34af15a870cf738
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb0 & libusbK driver support
Pete Batard wrote: > I have now pushed a patch that adds libusb0.sys and libusbK.sys > support there, for testing. I look forward to some testing! Even if it comes at the cost of the libusbK DLL it's still very nice that libusb-1.0 code can be used with the libusb-win32 driver. > To fetch the branch: > > git clone git://github.com/pbatard/libusbx.git libusbx-pbatard > cd libusbx-pbatard > git checkout 0K > > Note that because the branch is not off mainline, but off a personal > libusbx repo, you must go through a new clone. Both branches (master and 0K) in your personal repo have parents on libusbx.git master, so I suggest for everyone to simply add a remote and fetch from that in their existing worktrees, rather than making new clones. Repositories don't matter at all, only commits matter. > I should also point out that the implementation is very dependent on > the KUSB_FNID definitions from libusbK and their order, This seems fragile. Is there any more robust way? > The one minor issue I found is that I get the following in xusb when > trying to fetch the string descriptors of an XBox Controller device, > when libusb-win32 is used: > > Reading string descriptors: > libusbx: error [winusbx_submit_control_transfer] ControlTransfer failed: > [31] A device attached to the system is not functioning. > > That device doesn't have strings, so this is not a major issue, and the > libusb0 driver doesn't seem to have an issue returning strings for > devices that have them. It's just in case there are no strings that > libsusb0 seems to differ from the others and produces an error whereas > the other drivers don't complain. Interesting. Is the error definitely coming from the libusb0 driver, as opposed to libusbK? Which string descriptor is being read from the device by the way - because if there are no strings then all iFoobla descriptor fields should be 0, and then there will also be no descriptor 0, so then I would certainly expect an error for the control transfer. (Though the error code is a little surprising.) Did Travis help with this code too, besides libusbK providing WinUSB compatibility? This is a nice feature, so I think he deserves credit! Thanks, //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
