Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 25 Jan 2006 14:52:44 -0600

Al Honey wrote:

Seems to me that the overflow affects taskWd in such a way that the
memory corruption occurs at a low level and not from within the
application code (two different memory maps on two different IOCs with
two wildly different EPICS versions generating the same invalid
instruction address). If taskWd simply attempts to suspend the offending
task then does that mean the corruption occurs when the ring buffer
overflow message is generated (perhaps something as simple as a
malformed log message)?

taskWd is a watchdog task that exists to monitor a set of tasks and
report if/when they die. It was once used to restart some such tasks
automatically, but that functionality is no longer used. Thus it isn't
doing any task suspends at all, contrary to your assumption, although it
does periodically look at the TCBs (Task Control Blocks) of all its
tasks. I suspect the ring buffer overflow is related to the CA_event
task dying; it's just a conicidence that taskWd is informing you of that
occurrence at about the same time - that's what it's there for.
It's possible that something is corrupting the CA_event task's TCB. If
this happens again, do a 'd' of the memory area around the tid to see if
there's any ASCII text nearby, and have a look for where it might have
started from if it's a long ASCII stream - if you're lucky that might
give you some hints of the source.
- Andrew
--
* * Matt Santos / / For a Brighter America * *

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System