Experimental Physics and Industrial Control System
Public bug reported:
The IOC scan loops hung on all IOCs on several computers, on
investigation this looks to be caused by the monotonic clock wrapping.
The values of next and now in dbScan.c / periodicTask() are consistent
with GetTickCount() wrapping (which happens every 49.7 days), which I
believe lead to epicsEventWaitWithTimeout() being called with a large
delay. I was initially confused by the debugger saying a delay of 0 had
been passed to epicsEventWaitWithTimeout(), but I cannot see how this is
possible (the minimum delay should be penalty) so I assume the debugger
is reporting incorrectly due to the code being in release mode.
The epics Monotonic time functions should not normally be using
GetTickCount(), however it looks like the logic in the test for whether
to use GetPerformanceCounter() is inverted and so GetTickCount() is
always used. I will push a patch to fix this, and also to use
GetTickCount64() as a fallback instead (which wraps on a much longer
timescale).
** Affects: epics-base
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1896295
Title:
WIN32: IOC scan loops hang
Status in EPICS Base:
New
Bug description:
The IOC scan loops hung on all IOCs on several computers, on
investigation this looks to be caused by the monotonic clock wrapping.
The values of next and now in dbScan.c / periodicTask() are consistent
with GetTickCount() wrapping (which happens every 49.7 days), which I
believe lead to epicsEventWaitWithTimeout() being called with a large
delay. I was initially confused by the debugger saying a delay of 0
had been passed to epicsEventWaitWithTimeout(), but I cannot see how
this is possible (the minimum delay should be penalty) so I assume the
debugger is reporting incorrectly due to the code being in release
mode.
The epics Monotonic time functions should not normally be using
GetTickCount(), however it looks like the logic in the test for
whether to use GetPerformanceCounter() is inverted and so
GetTickCount() is always used. I will push a patch to fix this, and
also to use GetTickCount64() as a fallback instead (which wraps on a
much longer timescale).
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1896295/+subscriptions
- Replies:
- [Bug 1896295] Re: WIN32: IOC scan loops hang rivers via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang mdavidsaver via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang Freddie Akeroyd via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang Andrew Johnson via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang Freddie Akeroyd via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang Freddie Akeroyd via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang mdavidsaver via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang mdavidsaver via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang Freddie Akeroyd via Core-talk
- [Bug 1896295] Re: WIN32: IOC scan loops hang mdavidsaver via Core-talk
- Navigate by Date:
- Prev:
Re: Compiler warning question Benjamin Franksen via Core-talk
- Next:
[Bug 1896295] Re: WIN32: IOC scan loops hang rivers via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
[Bug 1895908] [NEW] epicsStackTraceTest fails on linux-aarch64 Andrew Johnson via Core-talk
- Next:
[Bug 1896295] Re: WIN32: IOC scan loops hang rivers via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024