Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 10 Nov 2005 10:34:11 -0700

Chris,

I am attempting to wrap up EPICS R3.14.8. I see that we 
still have mantis 207 outstanding - a problem detected on HPUX.

Here is the initial bug report.

> The test program works fine when I build against our 
> existing EPICS 3.13.2 installation, but there is a problem
> running with the newer EPICS version. The program performs the 
> channels access operations correctly, but the signal value 
> prints are sometimes followed by "epicsThreadOnceOsd 
> epicsMutexLock failed" written to the command shell. 
> I suspect the message is generated when I close the channel 
> and exit the program. The number of times the message is written 
> varies from zero to two. More often it is zero, and only once have 
> I seen two. Can anyone explain to me what this message means, and 
> what I need to do to correct it?

And another update.

> With regards to epics bug #207 on version 3.14.7 (hpux-parisc), 
> I have now seen the same diagnostic when using the caget that 
> comes bundled with the distribution. This eliminates the suspicion 
> I had about my test client having a bug.

I see that caget does not call ca_context_destroy (nor the legacy
ca_task_exit). 

I suspect that what has occurred is that CA threads are still 
running when your program exits. These problems probably occur when 
these thread continue to run after the C++ destructors for file scope 
objects run. That could cause the carpet to be yanked out 
from under these auxillary threads.

So at this point I see these possible options:

1) Call ca_context_destroy from all such applications prior to 
calling exit (or returning from main).

2) Obtain a stack trace from within your debugger for the failure
occuring from inside exit() - that can be hard to do depending on the
quality of HPUX debuggers. With the stack trace I might be able to
see better what is occurring and install a workaround. Given that 
this is occcurring on HPUX and not on other systems then I doubt
that I can make progress on a workaround w/o a stack trace.

No doubt that some developers would not list (2) as an option and 
claim that lack of (1) was the cause (pass the buck to the 
application).

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