Experimental Physics and Industrial Control System
I believe I have found a bug in e2db. In edifRead.c, in "int readcell(FILE
*file)",
new (struct cell)'s are constructed using the code
if (!chead)
chead = curcel = (struct cell *)malloc(sizeof (struct
cell));
else
{
curcel->flink = (struct cell *)malloc(sizeof (struct cell));
curcel = curcel->flink;
}
curcel->polink = (struct port *)NULL;
curcel->prlink = (struct prop *)NULL;
curcel->ilink = (struct instance *)NULL;
curcel->nlink = (struct net *)NULL;
Later in the program the list of cells is traversed using code like
for (cptr = chead; cptr != 0; cptr = cptr->flink) {...}
The problem is that flink is not being initialised. The last cell in the
list will contain an uninitialised flink pointer that may accidentally be
filled with 0, but may point to any random location in memory, causing the
program to crash when an attempt is made to access the contents of the bogus
cell.
The solution is simply to initialise flink:
if (!chead)
chead = curcel = (struct cell *)malloc(sizeof (struct
cell));
else
{
curcel->flink = (struct cell *)malloc(sizeof (struct cell));
curcel = curcel->flink;
}
/* The flink field was not being initialized. It should be set to
(struct cell *)NULL so that traversing the chead tree is
guaranteed to terminate. R. O. Redman, 2001-06-12 */
curcel->flink = (struct cell *)NULL;
curcel->polink = (struct port *)NULL;
curcel->prlink = (struct prop *)NULL;
curcel->ilink = (struct instance *)NULL;
curcel->nlink = (struct net *)NULL;
With this change the program seems to run (more) correctly.
There is a stylistic issue in that the for loop tests for the completion of
the loop using "flink != 0", instead of "flink != NULL". Practically, they
are the same test but since pointers are (or should be) initialised to NULL,
they should also be tested against NULL. This stylistic defect occurs in a
variety of places throughout the program.
I believe there is still another problem hidden somewhere in the code.
Quite routinely, when I make an error in the definition of the properties of
a record in my CapFast diagrams, the record is silently deleted from the
database. I believe the critical step is again e2db because the offending
records are present in the .edf file, but are missing in the .db file. No
error or warning mesages are issued. I have not yet been able to identify
which errors cause this behaviour, but I consider it a serious defect that
records can be dropped from the database without some error or warning
message being issued.
In a related issue, I normally place frames around all my CapFast diagrams.
These result in entries like the following in the .edf file:
(instance (rename frame "frame")
(viewRef NETLIST_VIEW
(cellRef bb200tr)))
Unfortunately, e2db tries to find the cell "bb200tr" that is being
referenced, and issues a lot of messages like
FATAL: Cannot find cell "bb200tr" in EDIF file.
In fact, this is not a fatal error because the missing "cell" is not
connected to anything, and e2db normally proceeds to produce a valid
database. It would be more appropriate for e2db to recognise that a frame
has no connections and can be ignored (unlike the real records).
Russell O. Redman
- Replies:
- Re: Bug in e2db Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Attaching other interface after VxWorks boot Andrew Johnson
- Next:
OSF bug Geoff Savage
- 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: Attaching other interface after VxWorks boot Vladis Korobov
- 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