EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/)
From: Rosemary Alles <[email protected]>
To: Rosemary Alles <[email protected]>
Cc: "Jeff Hill" <[email protected]>, [email protected]
Date: Wed, 5 Nov 2003 16:26:19 -1000 (HST)
results from compile: (HPUX gcc compile as with EPICS tools, same host) 

alles@mars:~/work/> ./assert.prob
tv_usec = 999999    
 
Seems fine, although the problem is intermittent. So...

??
rosemary. 



Rosemary Alles writes:
 > 
 > OK, Jeff. Will do.  Mahalo. Will send you the results.
 > 
 > ASIDE
 > -----
 > Why the problem surfaced in the recent past (< month )as 
 > opposed to  before remains a puzzle, given your theory.  
 > The program has run (without EPICS related changes) for 
 > approximately a (>)year without croaking.  Re: fdmgr_select(). No I
 > certainly don't call it directly. Also, aren't there other functions 
 > (in  libca/libcom)  calling osiSleep besides fdmgr_select()?
 > 
 > regards,
 > rosemary. 
 >     
 >  
 > 
 > Jeff Hill writes:
 >  > 
 >  > Aloha Rosemary Alles,
 >  > 
 >  > I have been looking at the source code and my best guess is that this has something to do with differences in the way that floating point numbers are converted to integers on your HPUX system. The obvious weakness with this theory is that it seems odd that the other HPUX sites have not experienced your problem before. Nevertheless, please compile the attached source code using the same tools used to prepare the executable that failed, run it on the same host that experienced your reported failure, and send the result. That should hopefully verify if my theory is or isnâ??t on the mark. This code segment could certainly have been written better.. It was written a long time ago and I can see how it could be made to be more portable. It could be more accurate also, but given the sleep granularity of most OS it is unlikely that there would be a measurable increase in the accuracy of the requested delay.
 >  > 
 >  > Looking at all of the code paths, another possibility might be that the anomalous tv_usec value came form a call your application made to fdmgr_select(), but I am going to guess not based on the information in your message.
 >  > 
 >  > Jeff
 >  > 
 >  > #include <stdio.h>
 >  > #include <float.h>
 >  > #include <time.h>
 >  > #include <assert.h>
 >  > 
 >  > struct timeval {
 >  >     long tv_sec;
 >  >     long tv_usec;
 >  > };
 >  > 
 >  > static const long USEC_PER_SEC = 1000000L;
 >  > 
 >  > void loadTimeVal ( double delay, struct timeval * pTimeVal )
 >  > {
 >  >     pTimeVal->tv_sec = (long) delay;
 >  >     pTimeVal->tv_usec =
 >  >         (long) ( ((delay)- pTimeVal->tv_sec)*USEC_PER_SEC );
 >  > }
 >  > 
 >  > int main ()
 >  > {
 >  >     struct timeval tv;
 >  >     unsigned i;
 >  > 
 >  >     for ( i = 0u; i < 1000000; i++ ) {
 >  >         loadTimeVal ( 1.0 - DBL_EPSILON, & tv );
 >  >         assert ( tv.tv_usec < USEC_PER_SEC );
 >  >     }
 >  > 
 >  >     printf ( "tv_usec = %ld\n", tv.tv_usec );
 >  > 
 >  >     return 0;
 >  > }
 >  > 
 >  > > -----Original Message-----
 >  > > From: Rosemary Alles [mailto:[email protected]]
 >  > > Sent: Wednesday, November 05, 2003 2:36 PM
 >  > > To: [email protected]
 >  > > Cc: [email protected]
 >  > > Subject: Assert failure in (?) osiSleep
 >  > > (*/epics/base/src/libCom/os/generic/)
 >  > > 
 >  > > 
 >  > > 
 >  > > 
 >  > > Aloha,
 >  > > 
 >  > > I have CA client program (basic client stuff: connect, write, put
 >  > > and monitor PVs) which has been running without a problem for
 >  > > over 1.5 years.  A week or so ago the IOC server code changed
 >  > > to version 3.13.8 from (I believe 3.13.0 beta). The client code
 >  > > is compiled with libraries from 3.13.6. The most recent compilation
 >  > > and release of the client code (modifications to which did not
 >  > > change/add any CA routines) crashes with the following core.
 >  > > 
 >  > > As far as I can tell the offending line is:
 >  > > (core will not respond to gdb -- permission issues)
 >  > > 
 >  > >  assert (uSec<1000000);
 >  > >  within */epics/base/src/libCom/os/generic/osiSleep.
 >  > > 
 >  > > (ASIDE: Albeit, from the core (below) it seems to go on to the fprintf
 >  > >  below the assert statement. :-( )
 >  > > 
 >  > > 
 >  > > Changes in client code
 >  > > ----------------------
 >  > > The only change in the client code was:
 >  > > 
 >  > > From:
 >  > > -----
 >  > >         time_t timeout;
 >  > >         time(&timeout);
 >  > >         timeout += 3;  /* 3 Seconds */
 >  > >         do {
 >  > >             ca_pend_event(LNG_DLY);
 >  > >             ----
 >  > >             ----
 >  > > 
 >  > >         )while (time(NULL) < timeout);
 >  > > 
 >  > > To:
 >  > > --
 >  > > 
 >  > >         time_t timeout;
 >  > >         time(&timeout);
 >  > >         timeout += 10;  /* 10 Seconds */
 >  > >         do {
 >  > >             ca_pend_event(LNG_DLY);
 >  > >             ----
 >  > >             ----
 >  > > 
 >  > >         )while (time(NULL) < timeout);
 >  > > 
 >  > > 
 >  > > LNG_DLY is defined to be 0.25
 >  > > 
 >  > > 
 >  > > Any ideas?
 >  > > 
 >  > > 
 >  > > >From the core:
 >  > > ------------------------------------------------------------
 >  > > 
 >  > > A call to "assert (%s)" failed in %s line %d.
 >  > > The file "core" will be created in the current working directory.
 >  > > Please save this file and the text of this message in order to assist
 >  > > in diagnosing this problem.
 >  > > Please send the text of this message to "%s"
 >  > > (the author of this call to assert()) or to "[email protected]"
 >  > > Please contact the author of this software or else send the text of
 >  > > this message to "[email protected]"
 >  > > This problem occurred in "%s"
 >  > > @(#)Version R3.13.6 $2002/03/13 14:44:06$%s replace of SIGPIPE failed
 >  > > beacuse %s
 >  > > ...../os/generic/sigPipeIgnore.c@¬rinpcb_rc_lock@��%li.%li.%li.%li:%i%li:
 >  > > %i%511s:%iinpcb_rc
 >  > > _lock@â?¡<Ukn Addr
 >  > > Type>%.*s:%hu%.*sinpcb_rc_lock@â?¡8../os/generic/osiSleep.cuSec<1000000er
 >  > > ror from select in osiDelayMicroSec() was %s
 >  > > errSymBld: Can't allocate storage
 >  > > errSymBld: ERROR - Module number in errSymTbl < 501 was Module=%lx
 >  > > Name=%s
 >  > > errSymBld: ERROR - errSymbolAdd() failed
 >  > > errSymbolAdd: Can't allocate storage
 >  > > err = %lderrSymDump: number of hash slots=%d
 >  > > ------------------------------------------------------------
 >  > > 
 >  > > Other stuff from the (mostly unreadable core)
 >  > > 
 >  > > ATDBF_SHORTDBF_STRINGTYPENOTCONNDBF_invalid@X
 >  > > @[@Zô@Zè@ZÃ?@ZÃ?@ZÃ?@Z¸@Z¨@ZË?@ZË?@Zx@Zh@ZX@ZH@Z8@Z(@Z@@Yø@Yè@YÃ?
 >  > > @YÃ?@Y¸@Y¨@YÅ?@YÂ?@Yâ??@Yt@Yd@YT@YD@Y4@Y$@Y@Y@Xô@Xä@XÃ?@XÃ?DBR_CLASS_NAMEDBR_ST
 >  > > SACK_STRINGDBR_PUT_ACKSDBR_PUT_ACKT
 >  > > DBR_CTRL_DOUBLEDBR_CTRL_LONGDBR_CTRL_CHARDBR_CTRL_ENUMDBR_CTRL_FLOATDBR_
 >  > > CTRL_SHORTDBR_CTRL_STRINGDBR_GR_DOU
 >  > > BLEDBR_GR_LONGDBR_GR_CHARDBR_GR_ENUMDBR_GR_FLOATDBR_GR_SHORTDBR_GR_STRIN
 >  > > GDBR_TIME_DOUBLEDBR_TIME_LONGDBR_TI
 >  > > ME_CHARDBR_TIME_ENUMDBR_TIME_FLOATDBR_TIME_SHORTDBR_TIME_STRINGDBR_STS_D
 >  > > OUBLEDBR_STS_LONGDBR_STS_CHARDBR_ST
 >  > > S_ENUMDBR_STS_FLOATDBR_STS_SHORTDBR_STS_STRINGDBR_DOUBLEDBR_LONGDBR_CHAR
 >  > > DBR_ENUMDBR_FLOATDBR_SHORTDBR_STRIN
 >  > > GDBR_invalid@[^L(@(#) caerr.h,v 1.15.2.1 2000/05/08 18:10:15 jba
 >  > > Exp@[ @eô@e�@e¬@e�@ep@e@@e@dü@d�@dx@dH@@cà
 >  > > @cË?@c\@c@@c@bð@bÃ?@bÂ?@bX@b
 >  > > @að@aÃ?@a°@al@a$@`à@`Å?@`X@`4@`^L@_è@_¸@_Å?@_l@_(@^ì@^¼@^x@^H@^^L@]ì@]Ã?@]¤@
 >  > > ]X@]D@]0@
 >  > > \ð@\¨@\d@\H@\,Invalid function pointerInvalid channel identifierData
 >  > > conversion between client's type and t
 >  > > he server's type failedThe search request/beacon address list was empty
 >  > > after initializationSorry, that ana
 >  > > chronistic feature of CA is no longer supportedWrite access deniedRead
 >  > > access deniedPut call back operation
 >  > >  collision with put call back operation in progressInvalid synchronous
 >  > > group identifierIO operations are in
 >  > >  progressIO operations have completedThe event selection mask supplied
 >  > > is empty or inappropriateNo internet
 >  > >  interface with broadcast availableServer (IOC) has fallen behind or is
 >  > > not responding- still waitingReseti
 >  > > ng dead connection- will try to reconnectNo channel id match for search
 >  > > reply- search reply ignoredUnable t
 >  > > o spawn the CA repeater thread- auto reconnect will failThe supplied
 >  > > string is emptyAttempt to use defunct
 >  > > CA feature failedSpecified task isnt a member of a CA contextNew or
 >  > > resumed network connectionRemote channe
 >  > > l has new network addressA monitor by that id cant be foundEvent queue
 >  > > overflow has prevented first pass ev
 >  > > ent after event addUnable to initialize without the vxWorks VX_FP_TASK
 >  > > task option setDatabase value get fo
 >  > > r that channel failed during channel searchThe CA routine called is
 >  > > inappropriate for use within an event h
 >  > > andlerAmbiguous channel host (multiple IOC's have a channel by that
 >  > > name)Network connection lostThe supplie
 >  > > d string has improper formatCount requested inappropriate for that
 >  > > channelCould not perform a database even
 >  > > t add for that channelCould not perform a database value put for that
 >  > > channelCould not perform a database v
 >  > > alue get for that channelThe requested local DB operation failedChannel
 >  > > Access Internal FailureUnable to lo
 >  > > cate all user specified channelsRemote Channel not foundThe type you
 >  > > have requested from this channel is un
 >  > > knownThe request was ignored because the specified channel is
 >  > > disconnectedThe supplied string is unusually
 >  > > largeSorry, that feature is planned but not supported at this timeUser
 >  > > specified timeout on IO operation ex
 >  > > piredThe array or data structure specified will not fit in CA message
 >  > > bufferRecord field specified inapprop
 >  > > riate for channel specifiedUnknown IO channelUnable to allocate
 >  > > additional dynamic memoryUnable to connect
 >  > > to internet host or serviceUnable to allocate a new socketUnknown
 >  > > internet serviceUnknown internet hostMaxi
 >  > > mum simultaneous IOC connections exceededNormal successful
 >  > > completion../access.cbytesSent == sizeof(msg)byt
 >  > > esSent == actualextsizen<=sizeof(nullBuff)bytesSent == nA.â??â?¬piiu-
 >  > > >sock_proto == I
 >  > > ------------------------------------------------------------
 >  > 

Replies:
RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Ralph Lange
References:
Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Rosemary Alles
RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Jeff Hill
RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Rosemary Alles

Navigate by Date:
Prev: RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Rosemary Alles
Next: RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Rosemary Alles
Next: RE: Assert failure in (?) osiSleep (*/epics/base/src/libCom/os/generic/) Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·