> Actually, AR does a core dump. No intentional aborts as far as I can see.
> Maybe we just have a REALLY old version of AR.
It calls assert(), which calls abort() when it fails, which generates a
SIGABRT signal, which will cause a core dump if the current working
directory is writable.
See assert(3) and abort(3).
It is quite intentional, and this isn't the only place AR dies in response
to a condition which is not a true error condition. Among other things, it
does not distinguish between a write "failure" due to the max file size
being exceeded and an actual error in writing to the file.
ARR has similar problems. For instance, if you are retrieving data and the
file size has changed since the last retrieval, it aborts(). Using the
"resync" item in the "retrieve" menu will prevent that. If the size
changes in the middle of the retrieve, you lose regardless. This makes it
harder to use on a "live" archive file than it should be.
- brian
- Replies:
- RE: EPICS archiver Jeff Hill
- References:
- Re: EPICS archiver Eugene T. Yamamoto
- Navigate by Date:
- Prev:
Re: EPICS archiver Eugene T. Yamamoto
- Next:
EPICS on vxWorks/x86 john sinclair
- 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:
Re: EPICS archiver Eugene T. Yamamoto
- Next:
RE: EPICS archiver Jeff Hill
- 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
|