Well, after over 6-months of inactivity, my NetBSD port for EPICS has again moved to the top of the priority queue for support of some field equipment.
I've pulled things off of my archive tapes, updated the components to the latest releases from the aps.anl site, and rebuilt them on a new, updated NetBSD system.
Now, whenever I start the system, I get the following message, and things "die" - as I would expect they would-:
â------------------------------------------------------------------------------------
A call to "assert (status==epicsMutexLockOK)" failed in ../dbLock.c line 247.
EPICS Release EPICS R3.14.9 $R3-14-9$ $2007/02/05 16:31:45$.
Current time Mon Nov 19 2007 09:38:29.509300158.
Please E-mail this message to the author or to [email protected]
Calling epicsThreadSuspendSelf()
Thread scan2 (0xbb630880) suspended
â------------------------------------------------------------------------------------
The same software operates without incident on my Linux development system, so I'm assuming it's something related to support under NetBSD that's the culprit. I'll start looking, but can anyone give me a pointer on where to start?
David Dudley
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:David Dudley
TEL;WORK:880-3740
ORG:;MIS
TEL;PREF;FAX:880-3741
EMAIL;WORK;PREF;NGW:[email protected]
N:Dudley;David
END:VCARD
- Replies:
- Re: Problem with assert in dbLock.c Andrew Johnson
- Navigate by Date:
- Prev:
RE: Power Supply Record? Denison, PN (Peter)
- Next:
Re: fanout processing and timed-out records Andrew Johnson
- 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:
question about caTCL_20070625 marco_hair
- Next:
Re: Problem with assert in dbLock.c Andrew Johnson
- 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
|