Using AD2 python interface - ctypes variable types

[Torfey]

We're using the 64 bit packages for Debian, writing our own python 2.7 code to access the provided AD2 library using 'ctypes' module. I'm trying to track down a tricky bug and wondering what the library was compiled with: C or C++ ?  Is the dwf.h definition file exactly correct with regards to parameter types (char vs unsigned char

Trying to see if the size of the parameters, ctypes.c_bool() vs ctypes.c_int(), e.g., matters. Or c_byte() vs c_ubyte().  Since afaik C doesn't have 'bool' type, knowing if this is a C++ library would help me decide.

Similar inconsistencies:

Example code snippet: /usr/share/digilent/waveforms/samples/py/dwfconstants.py

#TRIGSRC
trigsrcNone                 = c_byte(0)
trigsrcPC                   = c_byte(1)

But dwf.h, that presumaly the library was compiled with:

typedef unsigned char   BYTE;
typedef BYTE TRIGSRC;
const TRIGSRC trigsrcNone               = 0;
const TRIGSRC trigsrcPC                 = 1;

where my reference tells me 'c_ubyte' is what we should be using for 'unsigned char', not c_byte().

Going by the dwf.h file, I would not use the definition examples provided in dwfconstants.py, but change to c_ubyte(), for example.

In the end, most of these probably won't matter, but the bug I'm chasing seems to involve corruption of the runtime stack (moving a FDwf call into a subroutine gives different behavior than calling it from one up), so I'm being paranoid about the ctypes interface since it's easy to make a mistake there.

This on Debian 8.6 with installed:

+++-=======================-================-================-===================================================
ii  digilent.adept.runtime  2.16.5           amd64            Digilent Adept Runtime
ii  digilent.adept.utilitie 2.2.1            amd64            Digilent Adept Utilities
ii  digilent.waveforms      3.3.7            amd64            Digilent WaveForms

 

Thanks much.

[attila]

Hello,

You are right. This unsigned/signed shouldn't cause any issues is mostly aesthetic issue and it will be corrected. Thank you for the observation.

Regarding your problem, this could be caused by insufficient stack size. Try increasing it.

[Torfey]

Thanks for the input. Do you know if the source code is C or C++ ?

 

[attila]

Did the stack size change solve the problem ?

The source code is C++ but the API is C to have a more compatible library.

[Torfey]

Thanks.

The stack size on my linux seems to default to 8 KiB.  I've done 'ulimit -s 32768' to allow a process in that shell to try to increase more than the default.  But any call to threading.stack_size(32*1024) in my python leads to a segfault. I haven't tracked down yet who is segfaulting.  This is on an Intel NUC i5 with 64bit debian linux and 16G RAM.

I carefully went through all our calls from python to the C digilent library to make sure my variable types used in the calls matched what was declared in the dwf.h file. (ctypes.c_int() & ctypes.c_double() for example) but that made no difference to the strange behavior I get if push my initialization down one level into a subroutine instead of in _init_ of a class.    Had hoped that a wrong type was subtly corrupting the stack.

I haven't been able yet to confirm my hunch, but the bad raw data I get back after initializing from a subroutine 'appears' to be a first chunk of the trace then repeated two more times. 

[Torfey]

So maybe 'ulimit' is unrelated to threading.stack_size.  threading.stack_size(512*1024) doesn't segfault (at least not immed), but I'm still getting bad data when initializing from one level down in subroutine.