Re: Stack overflows

[Jeff Hill <johill@lanl.gov>]

David Terrett wrote:
> 
> I have just discovered the VxWorks "checkStack" command and find that
> after loading my system, bringing up a couple of dm screens and setting a
> couple of process variables one of the lines of output from checkStack
> reads:
> 
> CA client    _camsgtask   fff138    4760   264  4760      0 OVERFLOW
> 
> Should I be worried by this ? If so, what can I do about it ?
> 

Yes, this indicates that your stack has grown past its allocated space
and
it will therefore be corrupting other data structures in memory. This
of course could result in a system crash.

> I also believe that I am overflowing the stack in a subroutine attached to
> a subroutine record that is being scanned periodically. How can I increase
> the stack for a scan task ?
> 
> (I am using Epics 3.12.2)
> 

Most likely this is caused by an unusually long string of
interconnected records in your database. When the server
(running in camsgtask) calls db_put_field() for a passive
record recursive record processing results, and this can 
overflow the stack if you have a very long string of 
interconnected records.

In the latest patch release or R3.12.2 the file 
"$(EPICS)/base/include/task_params.h" has the following 
parameters in it:

#define CA_CLIENT_STACK         10000
#define EVENTSCAN_STACK         10000
#define SCANONCE_STACK          10000
#define CALLBACK_STACK          10000
#define PERIODSCAN_STACK        10000

You might find that bumping your copy of CA_CLIENT_STACK
to 10000 resolves your problem (after you rebuild 
the object codes in base and reboot the IOC).

Jeff

______________________________________________________________________
Jeffrey O. Hill                 Internet        johill@lanl.gov
LANL MS H820                    Voice           505 665 1831
Los Alamos, NM 87545 USA        FAX             505 665 5107