Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 16 Nov 2005 15:39:20 -0700

> However, I notice now that the labView system can only go through about
200
> edit/run cycles before they will run out of thread private variable
> allocations (on windows). Further investigation revealed that this is
> because epicsExit() was not being called by the test (and CAC now calls
> epicsAtExit instead of atexit). 

Problem 1:
The above indicates that we actually have an unfixed bug where they can only
do 200 edit/run cycles with labview because nothing is calling epicsExit,
and therefore CA's global cleanup (which frees the thread private variable
identifier) no longer runs because CA's calls to atexit were replaced by
calls to epicsAtExit. Apparently it is normal in labview VIs to runtime bind
with the DLL thereby allowing for the possibility of the DLLs being unloaded
if nothing in labView is currently using them. This maybe could be fixed if
the code unloading the DLL called epicsAtExit. However I'm not confident
that this would work because: A) I worry that maybe labView is the code that
unloads the DLL, and B) calling epicsExit() twice while a process is running
would probably cause a crash.

Problem 2:
Furthermore, I also vaguely recall that we had some kind of problem before
on windows when the atexit handler ran during DLL unload, but there were
various threads w/o graceful shutdown still running that were using the
stuff that was deallocated by atexit handlers.

O there was a return from main
O DLLs are unloaded and any atexit handler installed by code in the DLLs run
O crash occurs when stuff deallocated by atexit is used by a still actively
running threads
O we never get to the place where the windows NT process rundown terminates
threads that may still be running

Analysis:
We seem to be squeezing the bugs back and forth in the toothpaste tube so we
need to step back I think.

With problem 1 we have troubles because the graceful shutdown for the CA
client library does not run. Contrast that with problem 2 where we have
troubles because the graceful shutdown for the CA client library does run,
but threads in the system created by subsystems other than the CA client
library do not have a graceful shutdown. 

Soooo, what we have is a situation where most things in iocCore do not have
a gracefully shutdown. Therefore the current inclination is to just say that
R3.14 does not gracefully shutdown by design, and not call epicsExit. But
what is occurring is that this is inserting bugs into the CA client library
because its graceful shutdown doesn't run.

The bottom line is that the above may be dismissed as just a windows
platform peculiarity, due really to the quirky design of windows, and
therefore isn't really a valid concern. I will counter that if you exit from
main() and have threads still running then what you will have is OS specific
undefined behavior. It therefore may be hard to eliminate certain types of
poorly defined, OS (and OS version) specific, bugs until everything has a
graceful shutdown.

Jeff
__________________________________________________________
Jeffrey O. Hill               Mail         [email protected]
LANL MS H820                  Voice        505 665 1831
Los Alamos NM 87545 USA       Fax          505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System