Menu
▾
▴
libusbx-devel
|
From: Hans de G. <hde...@re...> - 2013-09-04 19:26:10
|
Hi, As discussed in much detail here: https://bugzilla.redhat.com/show_bug.cgi?id=1003193 Calling libusb_exit from atexit from libusb-compat-0.1.5 causes some apps to break. The app in question is the scanimage app from sane-backends, which uses atexit for cleanup itself. So what happens is the libusb-compat atexit handler runs first, and then the scanimage atexit cleanup code runs, and tries to cleanly shutdown the scanner (which may require communicating to it). This results in logs with LIBUSB_DEBUG=4 like this: [ 9.641307] [00006300] libusbx: debug [libusb_exit] [ 9.641312] [00006300] libusbx: debug [libusb_exit] destroying default context [ 9.641317] [00006300] libusbx: warning [libusb_exit] application left some devices open libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) libusbx: warning [libusb_close] internal signalling write failed, closing anyway scanimage: received signal 2 scanimage: trying to stop scanner libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9) scanimage: received signal 2 scanimage: aborting Note that errno 9 is EBADFD, which is caused by the fd already being closed by libusb_exit. I consider this behavior with some old apps a way bigger problem then the memory / resource leak we had before, therefor I suggest reverting the atexit changes to libusb-compat. Regards, Hans |
|
From: Igor F. <igo...@gm...> - 2013-09-22 08:15:16
|
Hi Recently I've ordered (and received) two USB based I2C/SPI interfaces from NANO River Technology http://nanorivertech.com/viperboard.html. This board is very useful for the LAB work during the evaluation and debugging of the, so called, 'first silicon'. Based on the sample code for Linux from NANO River, I've wrote a small CLI utility to talk to our DUTs from the terminal prompt. Everything works fine. Users are happy. There is just one thing they do not like. They are getting on their screen the following message: [~/I2C]$ i2c 2B AA BB -b 100kbit -U VIPER libusbx: warning [libusb_exit] application left some devices open Yes, I've installed the latest version of the libusbx package. We are running it on CentOS 6.4. Is there a trick (or workaround) to suppress the message ? Regards Igor |
|
From: Hans de G. <hde...@re...> - 2013-09-22 09:37:39
|
Hi, On 09/22/2013 10:14 AM, Igor Furlan wrote: > Hi > > Recently I've ordered (and received) two USB based I2C/SPI interfaces > from NANO River Technology http://nanorivertech.com/viperboard.html. > This board is very useful for the LAB work during the evaluation and > debugging of the, so called, 'first silicon'. > > Based on the sample code for Linux from NANO River, I've wrote a small > CLI utility to talk to our DUTs from the terminal prompt. > > Everything works fine. Users are happy. There is just one thing they > do not like. They are getting on their screen the following message: > > [~/I2C]$ i2c 2B AA BB -b 100kbit -U VIPER > libusbx: warning [libusb_exit] application left some devices open > > Yes, I've installed the latest version of the libusbx package. We are > running it on CentOS 6.4. > > Is there a trick (or workaround) to suppress the message ? Not really a trick or a workaround, you just need to make sure that your application properly closes any devices it has opened before exiting. Regards, Hans |
|
From: Igor F. <igo...@gm...> - 2013-09-22 22:01:36
|
On Sun, Sep 22, 2013 at 2:37 AM, Hans de Goede <hde...@re...> wrote: > Not really a trick or a workaround, you just need to make sure > that your application properly closes any devices it has opened > before exiting. Since I am not professional (or even semi professional) programmer, can you, please, point me to the doc | info | code snippet | hint , where I can learn how to close any devices properly. What I did until now, was to take the C++ code example from NANO River Tech web side and compile it on my system (CentOS 6.4). At that time, my CentOS had only the 'old' libusb installed. I am talking here about libusb 0.1 (legacy). Or, to be more specific, NANO River Tech uses http://nanorivertech.com/files/viper/linux/libusb-0.1.12.tar.gz. Their C++ code example works without any issue with the libusb 0.1. No problems with potentially opened devices at exit. There is another I2C interface I want to support with my i2c CLI utility. It is a DIMAX SUB-20 module ( http://www.xdimax.com/sub20/sub20.html ). Their C code example uses libusbx 1.0. So, I decided to install libusbx 1.0.16 + compat layer on the CentOS. This would cover both interface boards. Yes, the both boards work. The NANO board produces warnings about non closed devices at exit. The DIMAX board is OK Igor |
|
From: Ludovic R. <lud...@gm...> - 2013-09-22 09:43:33
|
2013/9/22 Igor Furlan <igo...@gm...>: > Hi Hello, > Recently I've ordered (and received) two USB based I2C/SPI interfaces > from NANO River Technology http://nanorivertech.com/viperboard.html. > This board is very useful for the LAB work during the evaluation and > debugging of the, so called, 'first silicon'. > > Based on the sample code for Linux from NANO River, I've wrote a small > CLI utility to talk to our DUTs from the terminal prompt. > > Everything works fine. Users are happy. There is just one thing they > do not like. They are getting on their screen the following message: > > [~/I2C]$ i2c 2B AA BB -b 100kbit -U VIPER > libusbx: warning [libusb_exit] application left some devices open > > Yes, I've installed the latest version of the libusbx package. We are > running it on CentOS 6.4. > > Is there a trick (or workaround) to suppress the message ? Are you using libusb-compat? if yes, can't you switch to libusbx directly? Bye -- Dr. Ludovic Rousseau |
|
From: Igor F. <igo...@gm...> - 2013-09-22 19:27:11
|
On Sun, Sep 22, 2013 at 2:43 AM, Ludovic Rousseau <lud...@gm...> wrote: > Are you using libusb-compat? > > if yes, can't you switch to libusbx directly? Yes, I am using libusb-compat. No, I can not switch to libusbx directly because: A) the example code from NANO River uses API based on libusb 0.1 B) my programming skills are not adequate to do the conversion C) I plan to support DIMAX SUB-20 board within the same i2c CLI utility D) their API (and example code) is based on libusbx 1.0 So, the libusbx+compat layer is ideal combo for my tiny i2c CLI utility. Or, perhaps, you know for some doc | guidance for "how to map legacy libusb 0.1 API to modern libusbx 1.0 API" ? Regards Igor |
|
From: Hans de G. <hde...@re...> - 2013-09-23 07:38:55
|
Hi, On 09/22/2013 09:17 PM, Igor Furlan wrote: > On Sun, Sep 22, 2013 at 2:37 AM, Hans de Goede <hde...@re...> wrote: >> Not really a trick or a workaround, you just need to make sure >> that your application properly closes any devices it has opened >> before exiting. >> >> Regards, >> >> Hans > > Since I am not professional (or even semi professional) programmer, > can you, please, point me to the doc | info | code snippet | hint , > where I can learn how to close any devices properly. > > What I did until now, was to take the C++ code example from NANO River > Tech web side and compile it on my system (CentOS 6.4). At that time, > my CentOS had only the 'old' libusb installed. I am talking here about > libusb 0.1 (legacy). Or, to be more specific, NANO River Tech uses > http://nanorivertech.com/files/viper/linux/libusb-0.1.12.tar.gz. Since you are using libusb-0.1 in this case the answer would be to call usb_close() on the usb_dev_handle returned by usb_open() before exiting the program. Regards, Hans |
|
From: Xiaofan C. <xia...@gm...> - 2013-09-05 01:15:03
|
On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede <hde...@re...> wrote: > Hi, > > As discussed in much detail here: > https://bugzilla.redhat.com/show_bug.cgi?id=1003193 > > Calling libusb_exit from atexit from libusb-compat-0.1.5 causes > some apps to break. > > The app in question is the scanimage app from sane-backends, which > uses atexit for cleanup itself. > > So what happens is the libusb-compat atexit handler runs first, and > then the scanimage atexit cleanup code runs, and tries to cleanly > shutdown the scanner (which may require communicating to it). > ... > I consider this behavior with some old apps a way bigger problem then the > memory / resource leak we had before, therefor I suggest reverting the > atexit changes to libusb-compat. > I agree. On the other hand, maybe we then have to document this limitation of libusb-compat. BTW, do we need to replicate the libusb.org libusb-compat tickets in libusbx github? Only Ticket 110 and 32 need to be copied as other tickets have been closed. http://www.libusb.org/report/10 If yes, then I will copy the two tickets and add "Compat" in the beginning of the description to distinguish them from libusbx tickets. -- Xiaofan |
|
From: Hans de G. <hde...@re...> - 2013-09-06 10:58:27
|
Hi, On 09/05/2013 03:14 AM, Xiaofan Chen wrote: > On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede <hde...@re...> wrote: >> Hi, >> >> As discussed in much detail here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1003193 >> >> Calling libusb_exit from atexit from libusb-compat-0.1.5 causes >> some apps to break. >> >> The app in question is the scanimage app from sane-backends, which >> uses atexit for cleanup itself. >> >> So what happens is the libusb-compat atexit handler runs first, and >> then the scanimage atexit cleanup code runs, and tries to cleanly >> shutdown the scanner (which may require communicating to it). >> ... >> I consider this behavior with some old apps a way bigger problem then the >> memory / resource leak we had before, therefor I suggest reverting the >> atexit changes to libusb-compat. >> > > I agree. > > On the other hand, maybe we then have to document this limitation > of libusb-compat. You mean simply document that atexit is used and apps must not make any calls from atexit because there are no ordering guarantees? Or you mean revert the patch and then document the resource leak ? Also what do others think? Pete ? Nathan ? > BTW, do we need to replicate the libusb.org libusb-compat tickets in > libusbx github? Only Ticket 110 and 32 need to be copied as other > tickets have been closed. > http://www.libusb.org/report/10 > > If yes, then I will copy the two tickets and add "Compat" in the > beginning of the description to distinguish them from libusbx tickets. I think we should not count on libusb.org trac being available for ever, so yes cloning open issues seems like a good idea. About adding a "Compat: " header to the description, wouldn't it be better to simply enable issue tracking on: https://github.com/libusbx/libusb-compat-0.1 Here: https://github.com/libusbx/libusb-compat-0.1/settings Instead, and then file issues for it here: https://github.com/libusbx/libusb-compat-0.1/issues ? Regards, Hans > > > |
|
From: Xiaofan C. <xia...@gm...> - 2013-09-07 09:31:15
|
On Fri, Sep 6, 2013 at 6:58 PM, Hans de Goede <hde...@re...> wrote: > On 09/05/2013 03:14 AM, Xiaofan Chen wrote: >> On the other hand, maybe we then have to document this limitation >> of libusb-compat. > > You mean simply document that atexit is used and apps must not make any > calls from atexit because there are no ordering guarantees? Or you mean revert > the patch and then document the resource leak ? If there are no better solution, then we should revert the patch and document the resource leak. > Also what do others think? Pete ? Nathan ? > > >> BTW, do we need to replicate the libusb.org libusb-compat tickets in >> libusbx github? Only Ticket 110 and 32 need to be copied as other >> tickets have been closed. >> http://www.libusb.org/report/10 >> >> If yes, then I will copy the two tickets and add "Compat" in the >> beginning of the description to distinguish them from libusbx tickets. > > I think we should not count on libusb.org trac being available for ever, > so yes cloning open issues seems like a good idea. > > About adding a "Compat: " header to the description, wouldn't it be > better to simply enable issue tracking on: > https://github.com/libusbx/libusb-compat-0.1 > > Here: > https://github.com/libusbx/libusb-compat-0.1/settings > > Instead, and then file issues for it here: > https://github.com/libusbx/libusb-compat-0.1/issues > Good idea. Done. -- Xiaofan |
|
From: Nathan H. <hj...@me...> - 2013-09-06 14:59:28
|
On Sep 6, 2013, at 4:58 AM, Hans de Goede <hde...@re...> wrote: > Hi, > > On 09/05/2013 03:14 AM, Xiaofan Chen wrote: >> On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede <hde...@re...> wrote: >>> Hi, >>> >>> As discussed in much detail here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1003193 >>> >>> Calling libusb_exit from atexit from libusb-compat-0.1.5 causes >>> some apps to break. >>> >>> The app in question is the scanimage app from sane-backends, which >>> uses atexit for cleanup itself. >>> >>> So what happens is the libusb-compat atexit handler runs first, and >>> then the scanimage atexit cleanup code runs, and tries to cleanly >>> shutdown the scanner (which may require communicating to it). >>> ... >>> I consider this behavior with some old apps a way bigger problem then the >>> memory / resource leak we had before, therefor I suggest reverting the >>> atexit changes to libusb-compat. >>> >> >> I agree. >> >> On the other hand, maybe we then have to document this limitation >> of libusb-compat. > > You mean simply document that atexit is used and apps must not make any calls > from atexit because there are no ordering guarantees? Or you mean revert > the patch and then document the resource leak ? > > Also what do others think? Pete ? Nathan ? I don’t like re-introducing a leak but it looks unavoidable in this case. There may be similar issues with the atexit function used by the darwin backend. I will take a look and see what I can do there. -Nathan |
|
From: Hans de G. <hde...@re...> - 2013-09-07 09:48:01
|
Hi, On 09/06/2013 04:58 PM, Nathan Hjelm wrote: > > On Sep 6, 2013, at 4:58 AM, Hans de Goede <hde...@re...> wrote: > >> Hi, >> >> On 09/05/2013 03:14 AM, Xiaofan Chen wrote: >>> On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede <hde...@re...> wrote: >>>> Hi, >>>> >>>> As discussed in much detail here: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1003193 >>>> >>>> Calling libusb_exit from atexit from libusb-compat-0.1.5 causes >>>> some apps to break. >>>> >>>> The app in question is the scanimage app from sane-backends, which >>>> uses atexit for cleanup itself. >>>> >>>> So what happens is the libusb-compat atexit handler runs first, and >>>> then the scanimage atexit cleanup code runs, and tries to cleanly >>>> shutdown the scanner (which may require communicating to it). >>>> ... >>>> I consider this behavior with some old apps a way bigger problem then the >>>> memory / resource leak we had before, therefor I suggest reverting the >>>> atexit changes to libusb-compat. >>>> >>> >>> I agree. >>> >>> On the other hand, maybe we then have to document this limitation >>> of libusb-compat. >> >> You mean simply document that atexit is used and apps must not make any calls >> from atexit because there are no ordering guarantees? Or you mean revert >> the patch and then document the resource leak ? >> >> Also what do others think? Pete ? Nathan ? > > I don’t like re-introducing a leak but it looks unavoidable in this case. There may be similar issues with the atexit function used by the darwin backend. I will take a look and see what I can do there. Well, alternatively we could document that libusb-compat uses atexit for cleanup, and that apps using it should either not access libusb from their own atexit handlers, or register their atexit handler after calling libusb_init (atexit handlers are called in reverse registration order). Regards, Hans |
|
From: Ludovic R. <lud...@gm...> - 2013-09-07 10:02:19
|
2013/9/7 Hans de Goede <hde...@re...>: > Well, alternatively we could document that libusb-compat uses atexit for cleanup, > and that apps using it should either not access libusb from their own atexit handlers, > or register their atexit handler after calling libusb_init (atexit handlers are > called in reverse registration order). If we ask maintainers to modify the code of their application using libusb-0.1 we should just tell the to use libusb-1.0 directly. The goal of libusb-compat is to allow "unmaintained" applications using the libusb-0.1 API to benefit from libusb-1.0 with no code change. We should not break this "contract". So I think the best is to keep the resource leak and avoid crashes. Bye -- Dr. Ludovic Rousseau |
|
From: Alan S. <st...@ro...> - 2013-09-07 15:36:11
|
On Sat, 7 Sep 2013, Ludovic Rousseau wrote: > 2013/9/7 Hans de Goede <hde...@re...>: > > Well, alternatively we could document that libusb-compat uses atexit for cleanup, > > and that apps using it should either not access libusb from their own atexit handlers, > > or register their atexit handler after calling libusb_init (atexit handlers are > > called in reverse registration order). > > If we ask maintainers to modify the code of their application using > libusb-0.1 we should just tell the to use libusb-1.0 directly. > > The goal of libusb-compat is to allow "unmaintained" applications > using the libusb-0.1 API to benefit from libusb-1.0 with no code > change. We should not break this "contract". > > So I think the best is to keep the resource leak and avoid crashes. Slightly off the original topic but perhaps still relevant... There are several Linux programs using libusb-0.1 that don't work with libusb-compat. The reason is that they perform some or all of their I/O using the usbfs API directly, relying on libusb merely for listing devices and opening the device files. In particular, they get the device's open file descriptor by abusing the interface and reading the value directly out of the private libusb usb_dev_handle structure. If libusb-compat were changed so that the initial parts of the usb_dev_handle structure were the same as in libusb-0.1 -- including the underlying file descriptor -- these programs might suddenly start working. (Note that doing this would require adding a function to the libusb-1.0 API for retrieving the low-level file descriptor.) Anybody feel like implementing this? Alan Stern |
|
From: Xiaofan C. <xia...@gm...> - 2013-09-09 01:30:34
|
On Sat, Sep 7, 2013 at 11:36 PM, Alan Stern <st...@ro...> wrote: > Slightly off the original topic but perhaps still relevant... > > There are several Linux programs using libusb-0.1 that don't work with > libusb-compat. The reason is that they perform some or all of their > I/O using the usbfs API directly, relying on libusb merely for listing > devices and opening the device files. In particular, they get the > device's open file descriptor by abusing the interface and reading the > value directly out of the private libusb usb_dev_handle structure. Just wondering if there are any important programs here. If there are not many, why not suggest them to move to libusbx API. Just wondering how easy for these program to migrate to mixed libusbx API and directly usbfs API. Or is it faster for them to use libusbx API and get rid of the usbfs API? I know one of them which is libftdi-0.x async I/O which use usbfs directly for Linux. Later libftdi1 migrates to libusb-1.0 API and the problem no longer exists. > If libusb-compat were changed so that the initial parts of the > usb_dev_handle structure were the same as in libusb-0.1 -- including > the underlying file descriptor -- these programs might suddenly start > working. (Note that doing this would require adding a function to the > libusb-1.0 API for retrieving the low-level file descriptor.) > > Anybody feel like implementing this? How feasible is this? I am not so sure if any one wants to further develop libusb-compat-0.1 other than bug fixes. Travis has done some work on integrating libusb-win32 async APIs into libusb-compat-0.1 but the work is not published. -- Xiaofan |
|
From: Alan S. <st...@ro...> - 2013-09-09 15:25:23
|
On Mon, 9 Sep 2013, Xiaofan Chen wrote: > On Sat, Sep 7, 2013 at 11:36 PM, Alan Stern <st...@ro...> wrote: > > Slightly off the original topic but perhaps still relevant... > > > > There are several Linux programs using libusb-0.1 that don't work with > > libusb-compat. The reason is that they perform some or all of their > > I/O using the usbfs API directly, relying on libusb merely for listing > > devices and opening the device files. In particular, they get the > > device's open file descriptor by abusing the interface and reading the > > value directly out of the private libusb usb_dev_handle structure. > > Just wondering if there are any important programs here. If there > are not many, why not suggest them to move to libusbx API. I don't know. Perhaps not many, but this may include a large percentage of unmaintained programs. For the one noteworthy case I am aware of (the Data Center program from Total Phase), I suggested to the vendor that they migrate to libusb-1. Evidently this had not occurred to them; instead they have been recommending various work-arounds to their customers. > Just wondering how easy for these program to migrate to > mixed libusbx API and directly usbfs API. Or is it faster for > them to use libusbx API and get rid of the usbfs API? I don't know. On the other hand, does libusbx provide an API for getting the OS's file descriptor from the device handle? > I know one of them which is libftdi-0.x async I/O which use usbfs > directly for Linux. Later libftdi1 migrates to libusb-1.0 API and > the problem no longer exists. > > > If libusb-compat were changed so that the initial parts of the > > usb_dev_handle structure were the same as in libusb-0.1 -- including > > the underlying file descriptor -- these programs might suddenly start > > working. (Note that doing this would require adding a function to the > > libusb-1.0 API for retrieving the low-level file descriptor.) > > > > Anybody feel like implementing this? > > How feasible is this? I doubt it would be very difficult, particularly since the changes can be restricted to operating systems that supported libusb-0.1 originally. > I am not so sure if any one wants to further develop libusb-compat-0.1 > other than bug fixes. Travis has done some work on integrating > libusb-win32 async APIs into libusb-compat-0.1 but the work is > not published. This isn't terribly important. If nobody does the work, it may not matter much. I noticed because for some time, Fedora has not provided libusb-0.1 support -- just libusb-compat (although for some reason the package is named "libusb", which made the situation rather confusing). In the end I had to get hold of an old source package for genuine libusb-0.1 and build it for my current system. It would be nice to spare other people the need to resort to such measures. Alan Stern |
Thanks for helping keep SourceForge clean.
X