Comment 10 for bug 1571224

Thanks Matt. This matches my thinking. So I think you will have even more trouble reproducing this crash with the patch applied :)

> Thread 1 (Thread 0x7f2a54eb7700 (LWP 4077)):
> #0 0x00007f2a6dfd9599 in ellDelete (pList=0x7f2a08000d60, pNode=0x7f2a0000d740) at ../../../src/libCom/ellLib/ellLib.c:87
> #1 0x00007f2a6ef3d289 in casAccessRightsCB (ascpvt=0x7f29ec001ab0, type=asClientCOAR) at ../camessage.c:1111
> #2 0x00007f2a6eb25122 in asComputePvt (asClientPvt=0x7f29ec001ab0) at ../asLibRoutines.c:1014
> #3 0x00007f2a6eb24ea0 in asComputeAsgPvt (pasg=0x10d9bb0) at ../asLibRoutines.c:940
> #4 0x00007f2a6eb23419 in asComputeAsg (pasg=0x10d9bb0) at ../asLibRoutines.c:455
> ...
> #9 0x00007f2a6e25b042 in cac::destroyIIU (this=0x7f2a2400ed20, iiu=...) at ../cac.cpp:1227
> #10 0x00007f2a6e2737e3 in tcpSendThread::run (this=0x7f2a18000a00) at ../tcpiiu.cpp:229
> #11 0x00007f2a6dfecc51 in epicsThreadCallEntryPoint (pPvt=0x7f2a18000a08) at ../../../src/libCom/osi/epicsThread.cpp:85
> ...

> Thread 30 (Thread 0x7f2a54db6700 (LWP 4012)):
> ...
> #5 0x00007f2a6dfede4f in epicsMutexLock (pmutexNode=0x10d9a60) at ../../../src/libCom/osi/epicsMutex.cpp:143
> #6 0x00007f2a6eb23118 in asRemoveClient (asClientPvt=0x7f2a0000d7b0) at ../asLibRoutines.c:391
> #7 0x00007f2a6ef39e8d in destroyAllChannels (client=0x7f2a08000d00, pList=0x7f2a08000d60) at ../caservertask.c:657
> #8 0x00007f2a6ef39fb4 in destroy_tcp_client (client=0x7f2a08000d00) at ../caservertask.c:688
> #9 0x00007f2a6ef3ae51 in camsgtask (pParm=0x7f2a08000d00) at ../camsgtask.c:164
> ...

By the time asRemoveClient() is called the channel has already been removed from chanList, but it's state has not been changed. So casAccessRightsCB() tries to ellDelete it again. My patch adds a new channel state rsrvCS_shutdown for when the channel is not in either of the two possible lists.