Hello Kate,
> A call to "assert (this->exitWait ( DBL_MAX ))" failed in
> ..../../../src/libCom/osi/epicsThread.cpp line 60.
Quite a few bugs have been fixed in R3.14 since R3.14.0.beta.2. You should
probably upgrade to a more recent release. This means re-linking MEDM with a
newer release. In particular, I can remember that there were some problems
with proper scheduling of single-threaded CA client applications like MEDM
in R3.14 beta releases.
The function epicsThread::exitWait () is fairly low level. It is called in
several places by the CA client library. Without a stack trace it is
difficult to make any further conclusions. If you can reproduce this in a
recent version then I can send instructions on how to get a stack trace from
the debugger.
I do not know what OS was involved. There were some problems with thread
shutdown procedures on Linux and also on HPUX in early R3.14 releases.
If you see this again with a recent version we definitely want to here about
it.
> 0xa36af0 (dnsQuery): Unhandled C++ exception resulted in call to
> terminate
It sounds like this problem is easy to reproduce. Please upgrade
R3.14.0.beta.2 to a newer version of R3.14. If the problem continues please
contact me and I will assist you with debugging the problem further (with
obtaining a stack trace).
Thanks for your bug report.
Jeff
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Kate Feng
> Sent: Monday, December 08, 2003 4:13 PM
> To: [email protected]
> Subject: "assert (this->exitWait ( DBL_MAX ))" failed
>
> Hi,
>
> I noticed the following message on the "medm screen"
> because today users complained that they could not pop up
> the xyz.adl file from the "related display" :
>
>
> A call to "assert (this->exitWait ( DBL_MAX ))" failed in
> ..../../../src/libCom/osi/epicsThread.cpp line 60.
> EPICS Release EPICS R3.14.0.beta.2 $R3-14-0-beta-2$ $2002/07/30
> 21:40:55$.
> Current time Tue Dec 02 2003 22:16:11.849753000.
> Please E-mail this message to the author or to [email protected]
> Calling epicsThreadSuspendSelf()
>
>
> It seems to be an intermittent problem because it is the first
> time that it occurs. Meanwhile, I could not load any new file
> via "File" from the original medm session. Without killing the
> original one, I opened another medm session and I was able
> to pop up the xyz.adl via "File" or the "related display".
> Something we can get around. It seems the IOC works fine.
>
> The platform :
> Medm version 3.03.
> The IOC is running R3.14.0.beta.2 VxWorks thread.
>
> One thing to mention is that :
> Whenever the IOC was first rebooted, I always got the following
> error message in the VxWorks thread (but never in the RTEMS
> thread. Unfortunately I did not run RTEMS on that IOC because
> I would have to borrow a mvme2306 from other projects to run) :
>
> 0xa36af0 (dnsQuery): Unhandled C++ exception resulted in call to
> terminate
>
> Something that was referenced in tech-talk "dnsQuery task suspended"
> by Geoff Savage on Sep. 5, 2003.
>
>
> However, it seems that the VxWorks IOC has been running fine for six
> months. The error message I mentioned on the top is
> found in the medm screen.
>
>
> Regards,
> kate
- References:
- "assert (this->exitWait ( DBL_MAX ))" failed Kate Feng
- Navigate by Date:
- Prev:
"assert (this->exitWait ( DBL_MAX ))" failed Kate Feng
- Next:
RE: Novice EPICS questions re yet another port David Kelly
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
"assert (this->exitWait ( DBL_MAX ))" failed Kate Feng
- Next:
Spurious link alarms generated? J. Frederick Bartlett
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|