Experimental Physics and Industrial Control System
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
- Navigate by Date:
- Prev:
mrkSoftTest doesn't compile Ralph Lange
- Next:
Re: 3.14.8@Linux: OSS priorities problem? Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: mrkSoftTest doesn't compile Ralph Lange
- Next:
online_notify.c Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024