【问题标题】:Can ctypes.data_as always be relied upon to keep references to temporaries?是否可以始终依赖 ctypes.data_as 来保留对临时对象的引用?
【发布时间】:2020-01-29 02:00:06
【问题描述】:

将数组从python 传递到后端c++ 库时,可以依赖以下内容吗?这曾经在python <= 3.6 中工作,但似乎导致python >= 3.7 中的偶尔崩溃:

(这是一个非常简化的“真实”代码版本,其中面向用户的python 接口在底层c++ lib 之间来回传递数据)

# a 2d array, possibly not order="F"
xmat = np.ones((16, 32), dtype=np.float64)

# get a pointer to a version of xmat that is guaranteed to have order="F"
# if xmat already has order="F": no temporary
# if not, a temporary copy is made, reordered and a ptr to that returned
xptr = np.asfortranarray(xmat).ctypes.data_as(ctypes.POINTER(ctypes.c_double))

# pass xptr to c++ back-end to do things (expects order="F" data)

据我所知(目前!)ctypes.data_as should:

将数据指针返回到特定的 c-types 对象...

返回的指针会保留对数组的引用。

还有一个示例表明,在创建临时对象的情况下,例如(a + b).ctypes.data_as(ctypes.c_void_p),使用data_as 是正确的做法。

python >= 3.7 中,data_as 似乎没有保留对临时的引用,而在上面,xptr 最终指向已释放的内存...

我做错了吗?这是python >= 3.7 中的错误吗?有没有更好的方法来做到这一点?


这里给出了一个完整的示例(带有一些额外的样板,将array 编组为后端库的struct):

import numpy as np
import ctypes as ct

lib_REALS_t = ct.c_double
lib_INDEX_t = ct.c_int32
lib_REALS_p = ct.POINTER(lib_REALS_t)

class lib_REALS_array_t(ct.Structure):
    _fields_ = [("size", lib_INDEX_t),
                ("data", lib_REALS_p)]

class lib_t(ct.Structure):
    _fields_ = [
    ("value", lib_REALS_array_t)]

def bug():

    libt = lib_t()

    # a 2d array, user-specified, possibly not order="F"
    xmat = np.ones((16, 32), dtype=np.float64, order="C")

    # get a pointer to a version of xmat that is guaranteed to have order="F"
    # if xmat already has order="F": no temporary
    # if not, a temporary copy is made, reordered and a ptr to that returned
    libt.value.size = xmat.size
    libt.value.data = np.asfortranarray(xmat).ctypes.data_as(ct.POINTER(lib_REALS_t))

    # pass xptr to c++ back-end to do things (expects order="F" data)

    # just "simulate" this by trying to access data using the pointer
    print(libt.value.data[1])

    return


if (__name__ == "__main__"): bug()

对我来说,python <= 3.6 打印 1.0(如预期的那样),而 python >= 3.7 打印 6.92213454250094e-310(即临时必须已被释放,因此指向未初始化的内存)。

【问题讨论】:

  • 你能提供一个可重现的例子吗?还有什么是OS,崩溃率等等?
  • @CristiFati: 崩溃率似乎是每次,os 是各种osxubuntuwindows 等。

标签: python numpy ctypes


【解决方案1】:

上市[Python 3.Docs]: ctypes - A foreign function library for Python

在调查并查看代码后,我得出了一个结论(我从一开始就凭直觉知道发生了什么)。

好像[SciPy.Docs]: numpy.ndarray.ctypes:

_ctypes.data_as(self, obj)

...

返回的指针将保留对数组的引用。

具有误导性。保留引用表示它将保存数组(内部)缓冲区地址(在某种意义上,它不会复制内存内容),而不会 Python 引用 (Py_XINCREF)。

看着[Github]: numpy/numpy - numpy/numpy/core/_internal.py

def data_as(self, obj):
    # Comments
    return self._ctypes.cast(self._data, obj)

这是对 ctypes.cast 的调用,它只保存源数组的缓冲区地址。

发生的情况是np.asfortranarray(xmat) 创建了一个临时数组(动态),然后ctypes.data_as 返回其缓冲区地址。在该行之后,临时对象超出范围(其缓冲区也是如此),但仍会引用其地址,从而产生 Undefined Behavior (UB )。

v1.15.0[SciPy.Docs]: numpy.ndarray.ctypes强调是我的))中提到了这一点:

小心使用 ctypes 属性 - 特别是在临时数组或动态构建的数组上。例如,调用(a+b).ctypes.data_as(ctypes.c_void_p)返回一个指向无效内存的指针,因为创建为 (a+b) 的数组在下一条 Python 语句之前被释放。您可以使用c=a+bct=(a+b).ctypes 来避免此问题。在后一种情况下,ct 将持有对数组的引用,直到 ct 被删除或重新分配。

但他们后来把它拿出来了(尽管代码没有被修改(关于这种行为))。

要克服错误,“保存”临时数组或保留 (Python) 引用[SO]: Access violation when trying to read out object created in Python passed to std::vector on C++ side and then returned to Python (@CristiFati's answer)也遇到了同样的问题。

我稍微修改了你的代码(包括那些糟糕的名字:))。

code00.py

#!/usr/bin/env python3

import sys
import ctypes as ct
import numpy as np
from collections import defaultdict


DblPtr = ct.POINTER(ct.c_double)

class Struct0(ct.Structure):
    _fields_ = [
        ("size", ct.c_uint32),
        ("data", DblPtr),
    ]


class Wrapper(ct.Structure):
    _fields_ = [
        ("value", Struct0),
    ]


def test_np(np_array, save_intermediary_array):
    wrapper = Wrapper()
    wrapper.value.size = np_array.size

    if save_intermediary_array:
        fortran_array = np.asfortranarray(np_array)
        wrapper.value.data = fortran_array.ctypes.data_as(DblPtr)
    else:
        wrapper.value.data = np.asfortranarray(np_array).ctypes.data_as(DblPtr)
    #print(wrapper.value.data[0])
    return wrapper.value.data[1]


def main(*argv):
    dim1, dim0 = 16, 32
    mat = np.ones((dim1, dim0), dtype=np.float64, order="C")
    print("NumPy CTypes data: {0:}\n{1:}".format(mat.ctypes, mat.ctypes._ctypes))

    dd = defaultdict(int)
    flag = 0  # Change to 1 to avoid problem
    print("Saving intermediary array: {0:d}".format(flag))
    for i in range(100):
        dd[test_np(mat, flag)] += 1
    print("\nResult: {0:}".format(dd))


if __name__ == "__main__":
    print("Python {0:s} {1:d}bit on {2:s}\n".format(" ".join(item.strip() for item in sys.version.split("\n")), 64 if sys.maxsize > 0x100000000 else 32, sys.platform))
    print("NumPy version: {0:}".format(np.version.version))
    main(*sys.argv[1:])
    print("\nDone.")

输出

e:\Work\Dev\StackOverflow\q059959608>sopr.bat
*** Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ***

[prompt]> "e:\Work\Dev\VEnvs\py_pc064_03.07.06_test0\Scripts\python.exe" code01.py
Python 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] 64bit on win32

NumPy version: 1.18.0
NumPy CTypes data: <numpy.core._internal._ctypes object at 0x000001C9744B0348>
<module 'ctypes' from 'c:\\Install\\pc064\\Python\\Python\\03.07.06\\Lib\\ctypes\\__init__.py'>
Saving intermediary array: 0

Result: defaultdict(<class 'int'>, {9.707134377684e-312: 100})

Done.

[prompt]> "e:\Work\Dev\VEnvs\py_pc064_03.07.06_test0\Scripts\python.exe" code01.py
Python 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] 64bit on win32

NumPy version: 1.18.0
NumPy CTypes data: <numpy.core._internal._ctypes object at 0x000001842ECA4FC8>
<module 'ctypes' from 'c:\\Install\\pc064\\Python\\Python\\03.07.06\\Lib\\ctypes\\__init__.py'>
Saving intermediary array: 0

Result: defaultdict(<class 'int'>, {1.0: 100})

Done.

[prompt]> "e:\Work\Dev\VEnvs\py_pc064_03.07.06_test0\Scripts\python.exe" code01.py
Python 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] 64bit on win32

NumPy version: 1.18.0
NumPy CTypes data: <numpy.core._internal._ctypes object at 0x000001AD586E91C8>
<module 'ctypes' from 'c:\\Install\\pc064\\Python\\Python\\03.07.06\\Lib\\ctypes\\__init__.py'>
Saving intermediary array: 0

Result: defaultdict(<class 'int'>, {9.110668798574e-312: 100})

Done.

[prompt]> "e:\Work\Dev\VEnvs\py_pc064_03.07.06_test0\Scripts\python.exe" code01.py
Python 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)] 64bit on win32

NumPy version: 1.18.0
NumPy CTypes data: <numpy.core._internal._ctypes object at 0x0000012F903A9188>
<module 'ctypes' from 'c:\\Install\\pc064\\Python\\Python\\03.07.06\\Lib\\ctypes\\__init__.py'>
Saving intermediary array: 0

Result: defaultdict(<class 'int'>, {6.44158096444e-312: 100})

Done.

注意事项

  • 所见结果非常随机,通常是 UB 指标
  • 有趣的是,在同一次运行中,它总是相同的值(defaultdict 只有一项)
  • flag 更改为 1(或任何评估为 True 的东西)将使问题消失

【讨论】:

  • @DarrenEngwirda:我意识到最后这是一个解释问题,但这回答了你的问题吗?如果是,请接受答案,以便其他人也能够承认([SO]: What should I do when someone answers my question?)。如果没有,请告诉我如何改进它,所以它会回答它。
【解决方案2】:

经过一段时间阅读ctypes 并寻找任何重大更改后,我能够通过添加代理变量来解决此问题。只需粘贴您的示例代码,我就可以轻松重现该问题。

我不太确定为什么会发生这种情况,但我可以猜测直接将指针分配给另一个指针,在ctypes 中存在错误。我也会寻找其他的可能性。但是现在,您可以通过添加如下代理变量来解决它:

def bug():

    libt = lib_t()

    # a 2d array, user-specified, possibly not order="F"
    xmat = np.ones((16, 32), dtype=np.float64, order="C")

    # get a pointer to a version of xmat that is guaranteed to have order="F"
    # if xmat already has order="F": no temporary
    # if not, a temporary copy is made, reordered and a ptr to that returned
    libt.value.size = xmat.size
    temp_p = np.asfortranarray(xmat).ctypes.data_as(ct.POINTER(lib_REALS_t))
    libt.value.data = temp_p

    # pass xptr to c++ back-end to do things (expects order="F" data)

    # just "simulate" this by trying to access data using the pointer
    print(libt.value.data[1])

    return

更新

嗯,根据@CristiFati 的回答,事实证明我实际上是无意中做了正确的事情。保留对实际数组的引用对我来说很有意义。我尝试打印指针的确切位置,并且每次都更改。所以我想如果我保留一次,它就不会再改变了;而且效果很好。

@CristiFati 做了非常好的调查。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-04-27
    • 2018-10-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-26
    相关资源
    最近更新 更多