We Keep Coding

Pointer to gpu memory to Python from CUDA C [duplicate]

I would like to call my C functions within a shared library from Python scripts. Problem arrises when passing pointers, the 64bit addresses seem to be truncated to 32bit addresses within the called function. Both Python and my library are 64bit.
The example codes below demonstrate the problem. The Python script prints the address of the data being passed to the C function. Then, the address received is printed from within the called C function. Additionally, the C function proves that it is 64bit by printing the size and address of locally creating memory. If the pointer is used in any other way, the result is a segfault.
CMakeLists.txt
cmake_minimum_required (VERSION 2.6)
add_library(plate MODULE plate.c)
plate.c
#include <stdio.h>
#include <stdlib.h>
void plate(float *in, float *out, int cnt)
{
void *ptr = malloc(1024);
fprintf(stderr, "passed address: %p\n", in);
fprintf(stderr, "local pointer size: %lu\n local pointer address: %p\n", sizeof(void *), ptr);
free(ptr);
}
test_plate.py
import numpy
import scipy
import ctypes
N = 3
x = numpy.ones(N, dtype=numpy.float32)
y = numpy.ones(N, dtype=numpy.float32)
plate = ctypes.cdll.LoadLibrary('libplate.so')
print 'passing address: %0x' % x.ctypes.data
plate.plate(x.ctypes.data, y.ctypes.data, ctypes.c_int(N))
Output from python-2.7
In [1]: run ../test_plate.py
passing address: 7f9a09b02320
passed address: 0x9b02320
local pointer size: 8
local pointer address: 0x7f9a0949a400

The problem is that the ctypes module doesn't check the function signature of the function you're trying to call. Instead, it bases the C types on the Python types, so the line...
plate.plate(x.ctypes.data, y.ctypes.data, ctypes.c_int(N))
...is passing the the first two params as integers. See eryksun's answer for the reason why they're being truncated to 32 bits.
To avoid the truncation, you'll need to tell ctypes that those params are actually pointers with something like...
plate.plate(ctypes.c_void_p(x.ctypes.data),
ctypes.c_void_p(y.ctypes.data),
ctypes.c_int(N))
...although what they're actually pointers to is another matter - they may not be pointers to float as your C code assumes.
Update
eryksun has since posted a much more complete answer for the numpy-specific example in this question, but I'll leave this here, since it might be useful in the general case of pointer truncation for programmers using something other than numpy.

Python's PyIntObject uses a C long internally, which is 64-bit on most 64-bit platforms (excluding 64-bit Windows). However, ctypes assigns the converted result to pa->value.i, where value is a union and the i field is a 32-bit int. For the details, see ConvParam in Modules/_ctypes/callproc.c, lines 588-607 and 645-664. ctypes was developed on Windows, where a long is always 32-bit, but I don't know why this hasn't been changed to use the long field instead, i.e. pa->value.l. Probably, it's just more convenient most of the time to default to creating a C int instead of using the full range of the long.
Anyway, this means you can't simply pass a Python int to create a 64-bit pointer. You have to explicitly create a ctypes pointer. You have a number of options for this. If you're not concerned about type safety, the simplest option for a NumPy array is to use its ctypes attribute. This defines the hook _as_parameter_ that lets Python objects set how they're converted in ctypes function calls (see lines 707-719 in the previous link). In this case it creates a void *. For example, you'd call plate like this:
plate.plate(x.ctypes, y.ctypes, N)
However, this doesn't offer any type safety to prevent the function from being called with an array of the wrong type, which will result in either nonsense, bugs, or a segmentation fault. np.ctypeslib.ndpointer solves this problem. This creates a custom type that you can use in setting the argtypes and restype of a ctypes function pointer. This type can verify the array's data type, number of dimensions, shape, and flags. For example:
import numpy as np
import ctypes
c_npfloat32_1 = np.ctypeslib.ndpointer(
dtype=np.float32,
ndim=1,
flags=['C', 'W'])
plate = ctypes.CDLL('libplate.so')
plate.plate.argtypes = [
c_npfloat32_1,
c_npfloat32_1,
ctypes.c_int,
]
N = 3
x = np.ones(N, dtype=np.float32)
y = np.ones(N, dtype=np.float32)
plate.plate(x, y, N) # the parameter is the array itself

If you don't tell ctypes what type the parameters are, it attempts to infer it from the values that you pass to the function. And this inference will not always work as you need.
The recommended way to deal with this is to set the argtypes attribute of the function and so explicitly tell ctypes what the parameter types are.
plate.plate.argtypes = [
ctypes.POINTER(ctypes.c_float),
ctypes.POINTER(ctypes.c_float),
ctypes.c_int
]
Then you can call the function like this:
plate.plate(x.ctypes.data, y.ctypes.data, N)

Actually, You should set plate.argstype = [ctypes.c_void_p, ctypes.c_void_p, ctypes.c_int], and then it will be ok to accept the address in c func from python.
I met the problem and I solved it as what I say.

Passing audio data from Python to C with ctypes

I have a C++ library which performs analysis on audio data, and a C API to it. One of the C API functions takes const int16_t* pointers to the data and returns the results of the analysis.
I'm trying to build a Python interface to this API, and most of it is working, but I'm having trouble getting ctypes pointers to use as arguments for this function. Since the pointers on the C side are to const, it feels to me like it ought to be possible to make this work fine with any contiguous data. However, the following does not work:
import ctypes
import wave
_native_lib = ctypes.cdll.LoadLibrary('libsound.so')
_native_function = _native_lib.process_sound_data
_native_function.argtypes = [ctypes.POINTER(ctypes.c_int16),
ctypes.c_size_t]
_native_function.restype = ctypes.c_int
wav_path = 'hello.wav'
with wave.open(wav_path, mode='rb') as wav_file:
wav_bytes = wav_file.readframes(wav_file.getnframes())
data_start = ctypes.POINTER(ctypes.c_int16).from_buffer(wav_bytes) # ERROR: data is immutable
_native_function(data_start, len(wav_bytes)//2)
Manually copying wav_bytes to a bytearray allows the pointer to be constructed but causes the native code to segfault, indicating that the address it receives is wrong (it passes unit tests with data read in from C++). Fixing this by getting the address right would technically solve the problem but I feel like there's a better way.
Surely it's possible to just get the address of some data and promise that it's the right format and won't be altered? I'd prefer not to have to deep copy all my Pythonically-stored audio data to a ctypes format, since presumably the bytes are in there somewhere if I can just get a pointer to them!
Ideally, I'd like to be able to do something like this
data_start = cast_to(address_of(data[0]), c_int16_pointer)
_native_function(data_start, len(data))
which would then work with anything that has a [0] and a len. Is there a way to do something like this in ctypes? If not, is there a technical reason why it's impossible, and is there something else I should be using instead?

This should work for you. Use array for a writable buffer and create a ctypes array that references the buffer.
data = array.array('h',wav_bytes)
addr,size = data.buffer_info()
arr = (c_short * size).from_address(addr)
_native_function(arr,size)
Alternatively, to skip the copy of wav_bytes into data array, you could lie about the pointer type in argtypes. ctypes knows how convert a byte string to a c_char_p. A pointer is just an address, so the _native_function will receive the address but use it as an int* internally:
_native_function.argtypes = c_char_p,c_size_t
_native_function(wav_bytes,len(wav_bytes) // 2)
Another way to work around the "underlying buffer is not writable" error is to leverage c_char_p, which allows an immutable byte string to used, and then explicitly cast it to the pointer type you want:
_native_function.argtypes = POINTER(c_short),c_size_t
p = cast(c_char_p(wav_bytes),POINTER(c_short))
_native_function(p,len(wav_bytes) // 2)
In these latter cases you must ensure you don't actually write to the buffer as it will corrupt the immutable Python object holding the data.

I had a look around at the CPython bug tracker to see if this had come up before, and it seems it was raised as an issue in 2011. I agree with the poster that it's a serious mis-design, but it seems the developers at that time did not.
Eryk Sun's comment on that thread revealed that it's actually possible to just use ctypes.cast directly. Here is part of the comment:
cast calls ctypes._cast(obj, obj, typ). _cast is a ctypes function pointer defined as follows:
_cast = PYFUNCTYPE(py_object,
c_void_p, py_object, py_object)(_cast_addr)
Since cast makes an FFI call that converts the first arg to c_void_p, you can directly cast bytes to a pointer type:
>>> from ctypes import *
>>> data = b'123\x00abc'
>>> ptr = cast(data, c_void_p)
It's a bit unclear to me if this is actually required by the standard or if it's just a CPython implementation detail, but the following works for me in CPython:
import ctypes
data = b'imagine this string is 16-bit sound data'
data_ptr = ctypes.cast(data, ctypes.POINTER(ctypes.c_int16))
The documentation on cast says the following:
ctypes.cast(obj, type)
This function is similar to the cast operator in C. It returns a new instance of type which points to the same memory block as obj. type must be a pointer type, and obj must be an object that can be interpreted as a pointer.
so it seems that that CPython is of the opinion that bytes 'can be interpreted as a pointer'. This seems fishy to me, but these modern pointer-hiding languages have a way of messing with my intuition.

Am I using ctypes correctly to pythonify this struct?

I'm trying to talk to this DLL using python's ctypes. Many of the functions take or return an HGRABBER type:
typedef struct HGRABBER_t__ { int unused; } HGRABBER_t;
#define HGRABBER HGRABBER_t*
(the full header file can be viewed here). Here's an example of a function prototype that returns an HGRABBER type:
HGRABBER __stdcall IC_CreateGrabber();
Here's my attempt at implementing this struct in python, and using it to call that function from the DLL:
import ctypes as C
class GrabberHandle(C.Structure):
_fields_ = [('unused', C.c_int)]
dll = C.windll.LoadLibrary('tisgrabber_x64.dll')
dll.create_grabber = dll.IC_CreateGrabber
dll.create_grabber.argtypes = []
dll.create_grabber.restype = GrabberHandle
my_handle = dll.create_grabber()
This seems to work, but I'm worried that I'm doing this wrong. I'm not experienced with C, and I don't think I understand the typedef and #define statements which define the HGRABBER type. Am I calling IC_CreateGrabber correctly? Should I have defined GrabberHandle to be a pointer to a struct, instead of a struct?
Thanks for reading, please let me know if I can clarify my question somehow.

You're right that you actually want a POINTER to the Structure, not the Structure itself.
Translating the C into English, being very loose (in a way that would be dangerous if you were trying to learn C but is good enough for using ctypes):
The struct defines a type named struct HGRABBER_t__, as a structure with one int in it.
The typedef defines a type named HGRABBER_t, as a synonym for struct HGRABBER_t__.
The #define defines a type named HGRABBER as a pointer to HGRABBER_t.
So, your GrabberHandle is the equivalent of HGRABBER_t; the equivalent of HGRABBER is:
GrabberHandlePtr = C.POINTER(GrabberHandle)
So you want this:
dll.create_grabber.restype = GrabberHandlePtr
It may be hard to debug the difference. A C struct with nothing but an int in it looks identical to an int in memory. And on Win32, an int and a pointer are both 32-bit values. And an int named unused is likely to be filled with meaningless garbage, making it hard to distinguish it from a pointer you've accidentally treated as an int. So everything will look fine, until you segfault 30 lines later in your code and have no idea what's wrong. :)

This library does what you are trying to do: https://github.com/morefigs/py-ic-imaging-control :)
But to answer your question, the library uses the code:
from ctypes import *
import os
class GrabberHandle(Structure):
pass
GrabberHandle._fields_ = [('unused', c_int)]
# set and check path
dll_path = os.path.join(os.path.expanduser('~'),
'Documents\\The Imaging Source Europe GmbH\\TIS Grabber DLL\\bin\\win32\\tisgrabber.dll')
with open(dll_path) as thefile:
pass
# open DLL
_ic_grabber_dll = windll.LoadLibrary(dll_path)
# create grabber
create_grabber = _ic_grabber_dll.IC_CreateGrabber
create_grabber.restype = POINTER(GrabberHandle)
create_grabber.argtypes = None
# get handle
handle = create_grabber()
Edit: changed code to use a pointer to GrabberHandle as per abarnert's answer as this is correct. However, in this particular case I have found no practical difference (with the 32-bit DLL), probably because the GrabberHandle structure is so simple.

Access Violation using Python Ctypes

I am trying to import and use a function from a DLL using Pythons ctypes module, but I keep getting this error:
Windows Error: exception: access violation writing 0x0000002C
I've had a look at the other questions on similar topics on here, but none seem to be able to provide an answer that works.
My current code is as follows:
from ctypes import *
dll = "./WinlicenseSDK/WinlicenseSDK.dll"
mydll = cdll.LoadLibrary(dll)
name = c_char_p("A.N. Body")
org = c_char_p("ACME")
pcID = c_char_p("APC44567")
zero = c_int(0)
licenseKey = create_string_buffer("")
mydll.WLGenLicenseFileKey(HASH, name, org, pcID, zero, zero, zero, zero, zero, licenseKey)
Context: I'm investigating licensing techniques for a piece of software. The above function generates a license key from hashing the parameters.
The last parameter for the WLGenLicenseFileKey is a string buffer that the generated key is written to.
I tried setting the argtypes for the function with mydll.WLGenLicenseFileKey.argtypes = ... but this won't work as there is not a string buffer ctypes raw type as there is for strings, ints, floats etc.
Can anybody tell me where I am going wrong?
EDIT:
The C/C++ function definition:
int WLGenLicenseFileKeyW(
wchar_t* pLicenseHash,
wchar_t* pUserName,
wchar_t* pOrganization,
wchar_t* pCustomData,
wchar_t* pMachineID,
int NumDays,
int NumExec,
SYSTEMTIME* pExpirationDate,
int CountryId,
int Runtime,
int GlobalTime,
char* pBufferOut
);
That is all the information that the documentation gives on the function.

The length of your licenseKey buffer is one byte, and you are not passing Unicode strings. I'm not in front of my PC, but I this should be close assuming your parameters are otherwise correct. Make sure to call the W version of the function. You also don't need to create the exact types as long as they are ints and pointers.
buffer = create_string_buffer(REQUIRED_BUFSIZE)
mydll.WLGenLicenseKeyW(u"A.N. Body", u"ACME", u"APC44567", None, None, 0, 0, None, 0, 0, 0, buffer)
If you do want to use argtypes, then this is what you want:
mydll.WLGenLicenseKeyW.argtypes = [c_wchar_t,c_wchar_t,c_wchar_t,c_wchar_t,c_wchar_t,c_int,c_int,c_void_p,c_int,c_int,c_int,c_char_p]
SYSTEMTIME would also need to be defined if you want to pass something besides NULL.
edit
I found some documentation. The function uses the stdcall calling convention, so use:
mydll = WinDLL(dll)

How do I create a Python ctypes pointer to an array of pointers

I need to learn how to handle the char** in the C++ method below through Python ctypes.
I was doing fine calling other methods that only need single pointers by using create_string_buffer(), but this method requires a pointer to an array of pointers.
ladybugConvertToMultipleBGRU32(
LadybugContext context,
const LadybugImage * pImage,
unsigned char** arpDestBuffers,
LadybugImageInfo * pImageInfo )
How do I create a pointer to an array of six create_string_buffer(7963648) buffers in ctypes to pass to this C++ method for writing?
arpDestBuffers = pointer to [create_string_buffer(7963648) for i in xrange(6)]
Thank you for any help.
Both the answers given below work. I just didn't realize I had another problem in my code which prevented me from seeing the results right away.
The first example is just as Luc wrote:
SixBuffers = c_char_p * 6
arpDestBuffers = SixBuffers(
*[c_char_p(create_string_buffer(7963648).raw) for i in xrange(6)] )
The second example coming from omu_negru's answer is:
arpDestBuffers = (POINTER(c_char) * 6)()
arpDestBuffers[:] = [create_string_buffer(7963648) for i in xrange(6)]
Both are accepted by the function and overwritten. Typing print repr(arpDestBuffers[4][:10]) before and after calling the function gives:
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
'\x15\x10\x0e\xff\x15\x10\x0e\xff\x14\x0f'
which shows that the function successfully overwrote the buffer with data.

Maybe Something like
SixBuffers = c_char_p * 6
arpDestBuffers = SixBuffers(*[c_char_p(create_string_buffer(7963648).raw) for i in xrange(6)])
Didin't try myself, so not sure that it works. Inspired by http://python.net/crew/theller/ctypes/tutorial.html#arrays

after you create all the string_buffers you need by calling create_string_buffer you can create an array for them with :
var=(POINTER(c_char)*size)() /* pointer_to_pointer */
Then you can fill it up by indexing it with var[index] and finally just call your function using it as an argument.... Works fine for me and i just tested it on a function with the signature void test_fn(char*,char**,unsigned char); written in C