Experimental Physics and
Industrial Control System

<[email protected]> · Wed, 30 Sep 2009 12:03:35 +0100

From: Juan Carlos Guzman <[email protected]>
> When using cothread-1-14 library on a linux x86_64 platform 
> (debian-etch kernel 2.6.24) the following error is displayed
> when doing a simple caget:
> 
> > > > print caget('ptf:pksmon:latJ2000')
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "build/bdist.linux-x86_64/egg/cothread/catools.py", line 653, in caget
>  File "build/bdist.linux-x86_64/egg/cothread/catools.py", line 116, in throw_wrapper
>  File "build/bdist.linux-x86_64/egg/cothread/catools.py", line 550, in caget_one
>  File "build/bdist.linux-x86_64/egg/cothread/cothread.py", line 696, in Wait
> cothread.catools.ca_nothing: new CA message number known only by server - see caerr.h
> 
> This error happens only in linux 64bit and not in 32bit or 
> darwin. I'm using EPICS base 3.14.10 and the IOC is running
> on linux-x86 (intel), numpy 1.3.0 and greenlet 0.2.
> 
> Any help will be greatly appreciated. Thanks in advance.

Unfortunately I don't seem to have a working 64-bit environment with channel access and access to PVs, and this report is my first practical experience with 64-bit!  I have a good idea what the problem is and how to fix it, but can you do a test for me please?

I first tried to reproduce a failing caget, but it's surprisingly hard to make caget fail once the connection has succeeded.  So my best bet is that actually your caget has succeeded (as far as ca_array_get_callback is concerned), but cothread has become muddled in interpreting the callback ... because I haven't specified the datatypes properly.  (Oops.)

Unfortunately (lack of 64-bit experience) I've treated long and int as synonymous, and also unfortunately in ctypes I have to manually translate the relevant parts of the channel access header files (please don't change them under me, guys!) into ctype declarations, and finally unfortunately I've never tested with 64-bits.  

In this particular case the status returned in response to ca_array_get_callback is the following structure (cadef.h):

typedef struct event_handler_args {
    void            *usr;   /* user argument supplied with request */
    chanId          chid;   /* channel id */
    long            type;   /* the type of the item returned */ 
    long            count;  /* the element count of the item returned */
    READONLY void   *dbr;   /* a pointer to the item returned */
    int             status; /* ECA_XXX status of the requested op from the server */
} evargs;

and the corresponding definition in cothread (cadef.py) is:

class event_handler_args(ctypes.Structure):
    _fields_ = [
        ('usr',     ctypes.py_object),  # Associated private data
        ('chid',    ctypes.c_int),      # Channel ID for this request
        ('type',    ctypes.c_int),      # DBR type of data returned
        ('count',   ctypes.c_int),      # Number of data points returned
        ('raw_dbr', ctypes.c_void_p),   # Pointer to raw dbr array
        ('status',  ctypes.c_int)]      # ECA_ status code of operation

Spot the multiple deliberate mistakes :(

Juan, can you please replace this structure with the following rather more correct version and let me know if cothread crashes somewhere else.  It *will* crash (because everything else is also wrong, in particular interpreting the dbr is probably going to go haywire which will definitely crash it, I'm going to work on fixing this and I'll mail a patch for you to test), but if I'm right the structure below will be a better match:

class event_handler_args(ctypes.Structure):
    _fields_ = [
        ('usr',     ctypes.py_object),  # Associated private data
        ('chid',    ctypes.c_void_p),   # Channel ID for this request
        ('type',    ctypes.c_long),     # DBR type of data returned
        ('count',   ctypes.c_long),     # Number of data points returned
        ('raw_dbr', ctypes.c_void_p),   # Pointer to raw dbr array
        ('status',  ctypes.c_int)]      # ECA_ status code of operation

You can also test this by printing out these fields in _caget_event_handler in catools.py.  I've attached a patch which does this and fixes this structure as above.  Please try this patch (apply with `patch -p1 -d/path/to/your/cothread <patch.txt`, re-run your caget and send me the output, please.

If you can let me know if I'm on the right path, I'll work through all the uses of ctypes and make sure the datatypes match properly and let you have a release candidate to test.

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System