Re: scan thread suspended

[Ralph Lange <Ralph.Lange@gmx.de>]

On 29.01.2013 11:33, Martin Konrad wrote:
> Hello,
> I just found a suspended thread on one of our IOCs:
>
> epics> epicsThreadShowAll
>             NAME EPICS ID PTHREAD ID OSIPRI OSSPRI STATE
>           _main_ 0x1e03190 0 0 0 OK
>           errlog 0x1e0d290 139706921178880 10 0 OK
>           taskwd 0x28268b0 139706921043712 10 0 OK
>       timerQueue 0x1e8bf60 139706920642304 70 0 OK
>            cbLow 0x1e8b710 139706840516352 59 0 OK
>         cbMedium 0x28163f0 139706839987968 64 0 OK
>           cbHigh 0x364bf00 139706839459584 71 0 OK
>         dbCaLink 0x1e11e60 139706838931200 50 0 OK
>       logRestart 0x1e12620 139706920908544 10 0 OK
>       timerQueue 0x1e12cf0 139706919847680 70 0 OK
>         scanOnce 0x41b08b0 139706837841664 70 0 OK
>           scan10 0x41ed360 139706837313280 60 0 OK
>            scan5 0x41ed600 139706836784896 61 0 OK
>            scan2 0x41ed8a0 139706836256512 62 0 OK
>            scan1 0x41edb40 139706835728128 63 0 SUSPEND
>          scan0.5 0x41edde0 139706835199744 64 0 OK
>          scan0.2 0x41ee080 139706834671360 65 0 OK
>          scan0.1 0x41ee320 139706834142976 66 0 OK
> ...
>
> What can cause a scan thread to be suspended? The IOC is using base
> R3.14.11-10. There are no messages in the IOC log. According to the
> log there was no user interaction using the IOC shell.

Martin,

what platform is this on? Linux?

Under vxWorks, the most common reason for a processing thread (scan or
callback) to get suspended are access faults, e.g. access to addresses
that have no hardware (memory, I/O) connected to them. Usually bugs in
device/driver support.
Under Linux, these create segmentation faults that crash the IOC, and I
haven't seen suspended processing threads yet.

~Ralph