[prev in list] [next in list] [prev in thread] [next in thread]
List: libusb-devel
Subject: Re: [libusb] Spinning event handlers maxing out the cpu? (libusb-1.0.20-rc3)
From: "David Granville" <openwindow () compuserve ! com>
Date: 2015-09-07 9:17:42
Message-ID: 006e01d0e94e$0e5ab190$2b1014b0$ () compuserve ! com
[Download RAW message or body]
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
This is a multipart message in MIME format.
Chris,
Hi, In the light of your email can I check that this is workable
In our hotplug callbacks if we restrict libusb calls to the following
libusb_ref_device
libusb_unref_device
libusb_get_device_descriptor
libusb_get_bus_number
libusb_get_port_number
libusb_get_device_speed
libusb_get_device_address
libusb_get_port_numbers
Simply to identify the device so we can continue processing it within an existing \
(our) context. We then spin off a thread to deal with the camera (and perform all the \
libusb sync IO). I don't think any of these are interruptible and don't have event \
handling loops under the covers.
Unfortunately we are currently calling open/transfer/close in error scenarios at this \
level. I will move those down to the thread handling.
Can I also double check with you that it is safe to call all of these on a detach \
callback?
Information from config.txt, is this sufficient re your question OS/Compiler?
hostname = beaglebone
uname -m = armv7l
uname -r = 3.8.13
uname -s = Linux
uname -v = #1 SMP Wed Sep 4 09:09:32 CEST 2013
configure:3357: checking for C compiler version
configure:3366: gcc --version >&5
gcc (Linaro GCC 4.7-2013.02-01) 4.7.3 20130205 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3377: $? = 0
configure:3366: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-angstrom-linux-gnueabi
Configured with: /build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/work-shared/gcc-linaro-4.7-r9/gcc-linaro-4.7-2013.02-01/configure \
--build=x86_64-linux --host=arm-angstrom-linux-gnueabi \
--target=arm-angstrom-linux-gnueabi --prefix=/usr --exec_prefix=/usr \
--bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share \
--sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib \
--includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info \
--mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking \
--with-libtool-sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone \
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix \
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu \
--enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- \
--without-local-prefix --enable-target-optspace --enable-lto --enable-libssp \
--disable-bootstrap --disable-libgomp --disable-libmudflap --with-system-zlib \
--with-linker-hash-style=gnu --with-ppl=no --with-cloog=no --enable-checking=release \
--enable-cheaders=c_global --with-sysroot=/ \
--with-build-sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone \
--with-native-system-header-dir=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone/usr/include \
--with-gxx-include-dir=/usr/include/c++/ --enable-nls
Thread model: posix
gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01)
Thanks
David Granville
From: Chris Dickens [mailto:christopher.a.dickens@gmail.com]
Sent: 07 September 2015 03:33
To: David Granville
Cc: libusb-devel@lists.sourceforge.net
Subject: Re: [libusb] Spinning event handlers maxing out the cpu? (libusb-1.0.20-rc3)
Hi David,
The root cause of the problem is the exact same as I explained here \
<http://sourceforge.net/p/libusb/mailman/message/34427046/> . Your hotplug callback \
is calling in to the sync API functions, which ultimately call in to do event \
handling. Recursive event handling is not possible because if the pollfd list \
changes, freed memory will be used when control returns to the top level. The timerfd \
constantly being read as triggered is most likely because the memory the original \
event handler was using has been re-purposed for something else. You would have \
likely encountered a SIGSEGV if the memory was completely freed.
There is one thing in your log that does concern me. It is evident in the following \
lines:
[47.775715] [000000d5] libusb: debug [handle_events] poll() 3 fds with timeout in \
60000ms
...
[47.837542] [000000d5] libusb: debug [usbi_remove_pollfd] remove fd 11
12:16:41.725093 Info {000000d5} Finished setting up processing camera
[47.839524] [000000d5] libusb: debug [handle_events] poll() 2 fds with timeout in 0ms
Note how the pollfd count changes from 3 to 2, but there is no message like the \
following seen between usbi_remove_pollfd() and handle_events():
[46.008302] [000000d5] libusb: debug [handle_events] poll fds modified, reallocating
This leads me to believe that the compiler is optimizing out the local variable that \
stores the pollfd count and is instead reading directly from the context. This is \
very troublesome and will lead to issues when devices are opened/closed. This can \
likely be addressed by making the variable volatile, but I'd like to verify this is \
indeed the case. Can you please let me know the OS/compiler you are using?
Regards,
Chris
On Sun, Sep 6, 2015 at 6:04 AM, David Granville <openwindow@compuserve.com> wrote:
Hi,
This is a follow on to issue raised last week, see "[libusb] libusb_control_transfer \
in thread does not complete", see below.
I am now using the code at libusb-1.0.20-rc3.
I have been seeing some strange cpu load activity when my docking station handles 8 \
cameras. I've tried to reproduce it with two but it never quite does the same thing \
but I've got some interesting repeated log entries which I suspect may be a prelude \
to the problem with 8 cameras.
To recap:
I have a multi threaded app.
Main thread inits libusb, sets up hotplug callbacks and performs a loop based around \
libusb_handle_events.
On each new hotplug connect event the device is examined and a new thread is spun up
Threads only using sync IO calls
In the two camera case the endless msgs start after a libusb_close
[47.837040] [000000d5] libusb: debug [libusb_close]
[47.837542] [000000d5] libusb: debug [usbi_remove_pollfd] remove fd 11
The loop consists of
[47.839524] [000000d5] libusb: debug [handle_events] poll() 2 fds with timeout in 0ms
[47.839713] [000000d5] libusb: debug [handle_events] poll() returned 2
[47.840143] [000000d5] libusb: debug [handle_events] caught a fish on the event pipe
[47.840279] [000000d5] libusb: debug [handle_events] someone updated the poll fds
[47.840397] [000000d5] libusb: debug [handle_events] timerfd triggered
[47.840843] [000000d5] libusb: debug [disarm_timerfd]
This gets repeated a hell of a lot albeit for only a few seconds – with 8 cameras \
it didn't get to stop and maxed out the cpu.
In the two camera case there are no libusb warnings or errors.
But in the 8 camera case we get
[57.766556] [00000120] libusb: error [op_handle_events] cannot find handle for fd \
925973048
Also repeated endlessly thru the rest of the log.
The log (1.0.36-endless fish 2) is available at http://1drv.ms/1KyzWWU
The 8-camera logs (cpumax)might eventually get uploaded to the same place.
I would greatly appreciate any help with this.
David Granville
From: Chris Dickens [mailto:christopher.a.dickens@gmail.com]
Sent: 04 September 2015 01:29
To: David Granville
Cc: libusb-devel@lists.sourceforge.net
Subject: Re: [libusb] libusb_control_transfer in thread does not complete
Hi David,
Thanks for reporting the issue and providing the logs. I was able to identify and \
correct the issue. Please try again using the latest code from libusb master.
Regards,
Chris
On Thu, Sep 3, 2015 at 2:19 PM, David Granville <openwindow@compuserve.com> wrote:
Hi,
Some help required please.
I am using code at https://github.com/dickens/libusb/tree/timeout-fix
At different points a libusb_control_transfer call never returns. There is no error \
nor timeout. The under the covers event handling process is not exited but continues \
and catches and performs Hotplug events on that thread.
Should this even be possible?
I have a multi threaded app.
Main thread inits libusb, sets up hotplug callbacks and performs a loop based around \
libusb_handle_events.
On each new hotplug connect event the device is examined and a new thread is spun up \
to deal with it. The thread only uses sync IO calls.
In this test there are two devices attached each with it's own thread for processing.
In the debug output (http://1drv.ms/1fDrqHD ) there is
[86.374213] [000000e5] libusb: debug [sync_transfer_cb] actual_length=20
which appears to be the last expected behaviour on the thread
after that we have repeats of
[86.487324] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] another \
thread is doing event handling
until
[87.074130] [000000e5] libusb: debug [libusb_try_lock_events] someone else is closing \
a device
[87.074202] [000000e5] libusb: debug [libusb_event_handler_active] someone else is \
closing a device
[87.074255] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] another \
thread is doing event handling
[87.075511] [000000e5] libusb: debug [libusb_try_lock_events] someone else is closing \
a device
[87.075635] [000000e5] libusb: debug [libusb_event_handler_active] someone else is \
closing a device
[87.075693] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] another \
thread is doing event handling
and then we have
[89.759882] [000000e5] libusb: debug [handle_events] poll() returned 1
[89.759964] [000000e5] libusb: debug [handle_events] caught a fish on the event pipe
[89.770460] [000000e5] libusb: debug [handle_events] hotplug message received
and the event is handled on this thread. This thread then does not terminate because \
the original call never returns.
The log finally shows two threads trying to service events, d7 the main thread and e5 \
the 'stuck' thread that hasn't returned from the libusb_control_transfer call.
[107.115592] [000000e5] libusb: debug [handle_events] poll() 3 fds with timeout in \
0ms
[107.116356] [000000e5] libusb: debug [handle_events] poll() returned 0
[107.117139] [000000d7] libusb: debug [libusb_handle_events_timeout_completed] doing \
our own event handling
[107.117248] [000000d7] libusb: debug [handle_events] poll() 3 fds with timeout in \
60000ms
[107.117692] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] \
another thread is doing event handling
[167.118573] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] \
another thread is doing event handling
[167.175212] [000000d7] libusb: debug [handle_events] poll() returned 0
[167.175392] [000000d7] libusb: debug [libusb_handle_events_timeout_completed] doing \
our own event handling
[167.175464] [000000d7] libusb: debug [handle_events] poll() 3 fds with timeout in \
60000ms
[167.175584] [000000e5] libusb: debug [libusb_handle_events_timeout_completed] \
another thread is doing event handling
David Granville
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991 \
<http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140> &iu=/4140 \
_______________________________________________ libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
------------------------------------------------------------------------------
_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-GB;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Chris,<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi, In the \
light of your email can I check that this is workable<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In our \
hotplug callbacks if we restrict libusb calls to the \
following<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_ref_device<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_unref_device<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_device_descriptor<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_bus_number<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_port_number<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_device_speed<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_device_address<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb_get_port_numbers<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Simply to \
identify the device so we can continue processing it within an existing (our) \
context. We then spin off a thread to deal with the camera (and perform all the \
libusb sync IO). I don't think any of these are interruptible and don't have event \
handling loops under the covers.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Unfortunately \
we are currently calling open/transfer/close in error scenarios at this level. I will \
move those down to the thread handling.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Can I also \
double check with you that it is safe to call all of these on a detach \
callback?<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Information \
from config.txt, is this sufficient re your question \
OS/Compiler?<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>hostname = \
beaglebone<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>uname -m = \
armv7l<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>uname -r = \
3.8.13<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>uname -s = \
Linux<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>uname -v = \
#1 SMP Wed Sep 4 09:09:32 CEST 2013<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>configure:3357: \
checking for C compiler version<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>configure:3366: \
gcc --version >&5<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>gcc (Linaro \
GCC 4.7-2013.02-01) 4.7.3 20130205 (prerelease)<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Copyright \
(C) 2012 Free Software Foundation, Inc.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This is \
free software; see the source for copying conditions. There is \
NO<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>warranty; \
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR \
PURPOSE.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>configure:3377: \
$? = 0<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>configure:3366: \
gcc -v >&5<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Using \
built-in specs.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>COLLECT_GCC=gcc<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>COLLECT_LTO_ \
WRAPPER=/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.7.3/lto-wrapper<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Target: \
arm-angstrom-linux-gnueabi<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Configured \
with: /build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/work-shared/gcc-linaro-4.7-r9/gcc-linaro-4.7-2013.02-01/configure \
--build=x86_64-linux --host=arm-angstrom-linux-gnueabi \
--target=arm-angstrom-linux-gnueabi --prefix=/usr --exec_prefix=/usr \
--bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share \
--sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib \
--includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info \
--mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking \
--with-libtool-sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone \
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix \
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu \
--enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- \
--without-local-prefix --enable-target-optspace --enable-lto --enable-libssp \
--disable-bootstrap --disable-libgomp --disable-libmudflap --with-system-zlib \
--with-linker-hash-style=gnu --with-ppl=no --with-cloog=no --enable-checking=release \
--enable-cheaders=c_global --with-sysroot=/ \
--with-build-sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone \
--with-native-system-header-dir=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone/usr/include \
--with-gxx-include-dir=/usr/include/c++/ --enable-nls<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thread \
model: posix<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>gcc version \
4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01)<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>David \
Granville<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><b><span lang=EN-US \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Chris Dickens \
[mailto:christopher.a.dickens@gmail.com] <br><b>Sent:</b> 07 September 2015 \
03:33<br><b>To:</b> David Granville<br><b>Cc:</b> \
libusb-devel@lists.sourceforge.net<br><b>Subject:</b> Re: [libusb] Spinning event \
handlers maxing out the cpu? (libusb-1.0.20-rc3)<o:p></o:p></span></p><p \
class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi \
David,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>The root cause of the problem is the exact same as I explained <a \
href="http://sourceforge.net/p/libusb/mailman/message/34427046/" \
target="_blank">here</a>. Your hotplug callback is calling in to the sync API \
functions, which ultimately call in to do event handling. Recursive event handling is \
not possible because if the pollfd list changes, freed memory will be used when \
control returns to the top level. The timerfd constantly being read as triggered is \
most likely because the memory the original event handler was using has been \
re-purposed for something else. You would have likely encountered a SIGSEGV if the \
memory was completely freed.<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There is one thing \
in your log that does concern me. It is evident in the following \
lines:<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>[47.775715] \
[000000d5] libusb: debug [handle_events] poll() 3 fds with timeout in \
60000ms<o:p></o:p></p></div><div><p class=MsoNormal>...<o:p></o:p></p></div><div><p \
class=MsoNormal>[47.837542] [000000d5] libusb: debug [usbi_remove_pollfd] remove fd \
11<o:p></o:p></p></div><div><p class=MsoNormal>12:16:41.725093 Info \
{000000d5} Finished setting up processing camera<o:p></o:p></p></div><div><p \
class=MsoNormal>[47.839524] [000000d5] libusb: debug [handle_events] poll() 2 fds \
with timeout in 0ms<o:p></o:p></p></div></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Note how the \
pollfd count changes from 3 to 2, but there is no message like the following seen \
between usbi_remove_pollfd() and handle_events():<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>[46.008302] \
[000000d5] libusb: debug [handle_events] poll fds modified, \
reallocating<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This leads me to \
believe that the compiler is optimizing out the local variable that stores the pollfd \
count and is instead reading directly from the context. This is very troublesome and \
will lead to issues when devices are opened/closed. This can likely be addressed by \
making the variable volatile, but I'd like to verify this is indeed the case. Can you \
please let me know the OS/compiler you are using?<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>Regards,<o:p></o:p></p></div><div><p \
class=MsoNormal>Chris<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>On Sun, Sep \
6, 2015 at 6:04 AM, David Granville <<a href="mailto:openwindow@compuserve.com" \
target="_blank">openwindow@compuserve.com</a>> wrote:<o:p></o:p></p><div><div><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,</span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This is a \
follow on to issue raised last week, see "[libusb] libusb_control_transfer in thread \
does not complete", see below.</span><o:p></o:p></p><p class=MsoNormal \
style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am now \
using the code at </span><span lang=EN-US \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>libusb-1.0.20-rc3</span><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>.</span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have been \
seeing some strange cpu load activity when my docking station handles 8 cameras. I've \
tried to reproduce it with two but it never quite does the same thing but I've got \
some interesting repeated log entries which I suspect may be a prelude to the problem \
with 8 cameras.</span><o:p></o:p></p><p class=MsoNormal \
style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p \
class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>To \
------------------------------------------------------------------------------
_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic