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: Problem with dbCaLink task in 3.14.4
From: "Mark Rivers" <[email protected]>
To: <[email protected]>
Date: Thu, 30 Oct 2003 23:54:19 -0600
Folks,

I am getting the following error when processing an EPICS "seq" record with CA links:

dbCaLink: A call to "assert ((epicsMutexLock((pca->lock))==epicsMutexLockOK))" failed in ..../dbCa.c at 757
Current time THU OCT 30 2003 18:48:42.968775352.
EPICS Release EPICS R3.14.4 $R3-14-4$ $2003/09/23 21:35:11$.
Please E-mail this message and the output from "tt (0x1558050)"
to the author or to [email protected]
filename="../../../src/libCom/taskwd/taskwd.c" line number=170
task 0x1558050 suspended

Here is the output of "tt":
ioc13lab> tt (0x1558050)
19e530 vxTaskEntry    +60 : 1a70bcc ()
1a70c1c epicsThreadPrivateGet+cc : dbCaTask ()
19ff9e0 dbCaTask       +2d4: epicsAssert ()
1a6f9dc epicsAssert    +f0 : epicsThreadSuspendSelf ()
1a70644 epicsThreadSuspendSelf+14 : taskSuspend ()
value = 0 = 0x0

The problem happens when the following record is processed:
grecord(seq,"$(P)AbortScansSEQ") {
        field(LNK1,"$(P)scanH.EXSC  CA MS")
        field(LNK2,"$(P)scan1.EXSC  CA MS")
        field(LNK3,"$(P)scan2.EXSC  CA MS")
        field(LNK4,"$(P)scan3.EXSC  CA MS")
        field(LNK5,"$(P)scan4.EXSC  CA MS")
}

This record is just writing 0 to the "EXSC" field of 5 "sscan" records using CA links.  The problem does not appear to be in the sscan record itself, because I can write to the .EXSC fields using CA from a client, or using "dbpf" from the vxWorks prompt, and it works fine.

Changing this record to:
grecord(seq,"$(P)AbortScansSEQ") {
        field(LNK1,"$(P)scanH.EXSC  PP MS")
        field(LNK2,"$(P)scan1.EXSC  PP MS")
        field(LNK3,"$(P)scan2.EXSC  PP MS")
        field(LNK4,"$(P)scan3.EXSC  PP MS")
        field(LNK5,"$(P)scan4.EXSC  PP MS")
}
i.e. using database links rather than CA links "fixes" the problem, and there are no errors.

I've attempted to reproduce the problem in a simple example application and have not been able to do so yet.

Any ideas what the problem could be?

Thanks,
Mark


Replies:
Re: Problem with dbCaLink task in 3.14.4 Marty Kraimer

Navigate by Date:
Prev: flash bootrom failure Geoff Savage
Next: Re: Problem with dbCaLink task in 3.14.4 Marty Kraimer
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: flash bootrom failure Geoff Savage
Next: Re: Problem with dbCaLink task in 3.14.4 Marty Kraimer
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 ·