Experimental Physics and Industrial Control System
Subject: |
Another possible problem in e2db |
From: |
"Redman, Russell O." <[email protected]> |
To: |
"Tech-Talk (E-mail)" <[email protected]> |
Date: |
Wed, 13 Jun 2001 10:44:12 -0700 |
I have located what may be a second problem in e2db, also related to
uninitialised pointers. This one is triggered by leaving states unmodified
in mbbi and mbbo records. For example, I have a record "conb:RTS:inSignals"
which defines the first four states ZRST="NSC_NDV", ONST="SC_NDV",
TWST="NSC_DV", and THST="SC_DV", but not any of the higher states. In the
edif file this becomes
(instance (rename inSignals "inSignals")
(viewRef NETLIST_VIEW
(cellRef embbisim))
(property (rename ZRVL "ZRVL")
(string "0"))
(property (rename ZRST "ZRST")
(string "NSC_NDV"))
(property (rename TWVL "TWVL")
(string "2"))
(property (rename TWST "TWST")
(string "NSC_DV"))
(property (rename THVL "THVL")
(string "3"))
(property (rename THST "THST")
(string "SC_DV"))
(property (rename ONVL "ONVL")
(string "1"))
(property (rename ONST "ONST")
(string "SC_NDV")))
The cellRef to "embbisim" provides default definitions for the other
properties:
(cell (rename embbisim "embbisim")
(cellType GENERIC)
(view NETLIST_VIEW (viewType NETLIST)
(interface
... skipping the ports and most of the other properties ...
(property (rename FVST "FVST")
(string ""))
(property (rename FTVL "FTVL")
(string "0"))
(property (rename FTSV "FTSV")
(string "NO_ALARM"))
(property (rename FTST "FTST")
(string ""))
(property (rename FRVL "FRVL")
(string "0"))
(property (rename FRSV "FRSV")
(string "NO_ALARM"))
(property (rename FRST "FRST")
(string ""))
It will be noted that FRST, FVST, etc are correctly assigned default values
"".
In the final .db file, however, we find
record(mbbi,"conb:RTS:inSignals") {
field(DESC,"multibit binary input rec")
field(SCAN,"Passive")
field(PINI,"NO")
field(PHAS,"0")
field(EVNT,"0")
field(DTYP,"Soft Channel")
field(DISV,"1")
field(SDIS,"0.000000000000000e+00")
field(DISS,"NO_ALARM")
field(PRIO,"LOW")
field(FLNK,"0.000000000000000e+00")
field(NOBT,"0")
field(INP,"0.000000000000000e+00")
field(ZRVL,"0")
field(ONVL,"1")
field(TWVL,"2")
field(THVL,"3")
field(FRVL,"0")
... skipping FVVL, etc ...
field(ZRST,"NSC_NDV")
field(ONST,"SC_NDV")
field(TWST,"NSC_DV")
field(THST,"SC_DV")
field(FRST,"<CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD>
<CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD>
<CD>
<CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD>
<CD>
<CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD><CD>
<CD>
<CD><CD><CD><CD><FD><FD><FD><FD><D1>")
and FVST, SXST, etc are all bit-wise identical to FRST. These values should
still be "". The database causes dbLoadRecords to freeze. My
investigations over the last week has sensitized me to the likelihood that
the repeated bit pattern <CD> is a probably indicator of an uninitialized
pointer.
Checking through edifRead, we find that properties are represented by
struct prop {
struct prop *flink; /* link to next prop */
char name[NL]; /* property name */
char val[NL]; /* property value string */
};
which are malloced from the heap. The prop.name and prop.val fields are not
initialized, and represent 80 characters (NL=80) of random memory. From the
edif fragment, these fields are read as strings in the procedures readprop
in edifRead.c. The relevant fragment is
case STRING:
getval(file, 0);
if (sscanf(edif_temp, "%s", junk) == -1)
readstring(file, level);
else
strncpy(curprop->val, edif_temp,
NL);
break;
where "edif_temp" has been filled with the value of the string, "" in this
case which means edif_temp[0]==EOS. The sscanf will fail to read a string
and will return -1, so that readstring is invoked to fill in the field.
However, readstring looks for a key STRINGDISPLAY, which does not exist, and
therefore does nothing. The result is that nothing is ever assigned to the
prop.val string. A solution is to initialise curprop->val to "" before
calling readstring. Note that this is harmless if readstring actually finds
a value. Thus the modified code for readprop becomes
case STRING:
getval(file, 0);
if (sscanf(edif_temp, "%s", junk) == -1)
{
/* initialise curprop->val in case
readstring does not
find anything either, R. O.
Redman 2001-06-13 */
strcpy(curprop->val,"");
readstring(file, level);
}
else
strncpy(curprop->val, edif_temp,
NL);
break;
With this change, the database is now generated correctly:
record(mbbi,"conb:RTS:inSignals") {
field(DESC,"multibit binary input rec")
field(SCAN,"Passive")
field(PINI,"NO")
field(PHAS,"0")
field(EVNT,"0")
field(DTYP,"Soft Channel")
field(DISV,"1")
field(SDIS,"0.000000000000000e+00")
field(DISS,"NO_ALARM")
field(PRIO,"LOW")
field(FLNK,"0.000000000000000e+00")
field(NOBT,"0")
field(INP,"0.000000000000000e+00")
field(ZRVL,"0")
field(ONVL,"1")
field(TWVL,"2")
field(THVL,"3")
field(FRVL,"0")
... skipping FVVL, etc ...
field(ZRST,"NSC_NDV")
field(ONST,"SC_NDV")
field(TWST,"NSC_DV")
field(THST,"SC_DV")
field(FRST,"")
field(FVST,"")
field(SXST,"")
I have attached my modified version of edifRead.c. This file now has two
changes from the original. Look for "Redman" to find them.
Cheers,
Russell O. Redman
Attachment:
edifRead.c
Description: Binary data
- Navigate by Date:
- Prev:
OSF bug Geoff Savage
- Next:
Re: Bug in e2db Benjamin Franksen
- 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:
OSF bug Geoff Savage
- Next:
Re: Bug in e2db and "FATAL error" Rozelle Wright
- 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