Re: EPICS Base Release 3.14.6

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Andrew,

as I posted last week, there is a bug in dbAccess.c that can crash the 
ioc when DTYP is read via CA. The bug is still present in the newly 
released 3.14.6. I think it has been there from the very beginning of 
EPICS. As I tested today, a Linux ioc also crashes (segmentation fault). 
 That there were no crashes on 68k processors seems to be coincidental 
(or just luck).

The problem is that for records without device support (calc, etc.) the 
dbDeviceMenu pointer is NULL. When it is dereferenced in 
get_enum_strs(), no check is done and pdbDeviceMenu->nChoice and 
pdbDeviceMenu->papChoice have arbitrary values.

Since I consider crashing an ioc with a read a major bug, I would be 
pleased to see this fixed in at least the latest version.

Dirk


Andrew Johnson wrote:
> EPICS Base release 3.14.6 has been available for download since last 
> Friday, but we didn't have the IOC Application Developers Guide in place 
> until today, hence the delayed release announcement.  This version of 
> Base contains many minor enhancements and bug fixes, especially to the 
> Channel Access client library, which is significantly more robust and 
> reliable than R3.14.5 was.
>
> There is a known problem with compiling this release against Tornado 
> 2.2, although the failure happens when building a test program after 
> everything required for normal use has been compiled, so this is 
> benign.  There may also be an issue when building some extensions using 
> the solaris-sparc-gnu architecture, but that's unconfirmed at present 
> (we hope Janet gets better soon).
>
> Thanks to all the core development team.
>
> - Andrew



Dirk Zimoch wrote:
> Hi all,
>
> at least on all EPICS releases 3.13.2 to 3.13.9, is a bug that causes crashes on PPC iocs. (I have not seen a 68k crash here.)
>
> Bug:
>
> When reading the DTYP field of "pure soft records" such as calc via CA, the CA_client task crashes and leaves the ioc in a state where no further access via CA is possible.
>
> data access
> Exception current instruction address: 0x01705f54
> Machine Status Register: 0x0000b030
> Data Access Register: 0xf0f0f0f0
> Condition Register: 0x28000040
> Data storage interrupt Register: 0x40000000
> Task: 0x17c31f0 "CA_client"
>
> > tt
> 17807c vxTaskEntry    +60 : camsgtask ()
> 1727a44 camsgtask      +2e4: camessage ()
> 172a7f0 camessage      +120: read_action ()
> 17286bc read_action    +e8 : read_reply ()
> 17284b4 read_reply     +144: db_get_field ()
> 171f838 .L198          +40 : dbGetField ()
> 1707650 dbGetField     +164: dbGet ()
> 1707760 dbGet          +cc : getOptions ()
> 17065d8 getOptions     +208: get_enum_strs ()
>
> Fix:
>
> *** base/src/db/dbAccess.c.orig Thu Jun  3 18:04:26 2004
> --- base/src/db/dbAccess.c      Thu Jun  3 18:10:33 2004
> ***************
> *** 129,134 ****
> --- 129,138 ----
>                     goto choice_common;
>                 case DBF_DEVICE:
>                     pdbDeviceMenu = (dbDeviceMenu *)pdbFldDes->ftPvt;
> +                   if (pdbDeviceMenu == NULL) {
> +                       no_str = 0;
> +                       goto choice_common;
> +                   }
>                     no_str = pdbDeviceMenu->nChoice;
>                     papChoice = pdbDeviceMenu->papChoice;
>                     goto choice_common;
>
>
> After this fix, calc records and the like report DTYP as 0.
>
> Dirk



--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413