| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Possible bug in taskwd |
| From: | "Thompson, David H." <[email protected]> |
| To: | EPICS tech-talk <[email protected]> |
| Date: | Wed, 13 Apr 2005 18:32:40 -0400 |
|
I am not sure what versions of Epics base/vxWorks this
applies to, we noticed it on R3.14.7/VxWorks 5.5.1. We looked at taskwd because we saw
it bus-error out and leave the IOC unable to accept new connections. I don’t think what I am reporting necessarily
has anything to do with the current problem; I just noticed that it might be a
bug. As I understand it, taskwd, is
supposed to monitor registered tasks so that when one of them gets unexpectedly
into a suspended state some action can be taken. In our case, taskwd
was suspended and no other task appeared in the list as suspended. Looking at source code, I see that on
vxWorks the taskwd main loop calls epicsThreadIsSuspended() which in turn calls taskIsSuspended()
in the vxWorks kernel. Looking
there, to see if there might be a cause for the bus error, I noticed that the
logic of the routine might not match the semantics that the taskwd
is expecting. Here is the problem, if the task is suspended, the function
returns TRUE to taskwd, if the task is not suspended
or is non-existent, deleted, the function returns FALSE. Seems to me that taskwd would want
to know the difference between “running” and “dead”. Maybe the loss of connectivity lies in a
dead task that no longer shows up in the task list. Just an observation. |