【问题标题】:C++ or Cython memory leakage?C++ 或 Cython 内存泄漏?
【发布时间】:2013-08-27 17:51:40
【问题描述】:

我正在开发一个用 cython 编写的 python 扩展模块,它包装了我编写的 C++ 类。

崩溃

我有一个简单的 python 代码,可以导入这个 python 模块并用它处理一些数据。现在,大约 4 次中的 1 次,程序在终止之前,在调用模块之后出现段错误。这也意味着所有数据都得到了正确处理。它的段错误是这样的:

/Users/axe/anaconda/bin/python.app: line 2: 73168 Segmentation fault: 11

用gdb调试,运行gdb python然后run code.py,我明白了

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001000894ae in PyObject_ClearWeakRefs ()

backtrace 的输出是

#0  0x00000001000894ae in PyObject_ClearWeakRefs ()
#1  0x00000001010edae4 in array_dealloc ()
#2  0x000000010007503e in tupledealloc ()
#3  0x00000001000559b7 in insertdict_by_entry ()
#4  0x0000000100059177 in PyDict_SetItem ()
#5  0x000000010005d286 in _PyModule_Clear ()
#6  0x00000001000df8cd in PyImport_Cleanup ()
#7  0x00000001000f0027 in Py_Finalize ()
#8  0x0000000100107e1b in Py_Main ()
#9  0x0000000100000f54 in start ()

所以段错误发生在我的 python 代码之外。我提到如果我从 ipython 中运行代码,或者将解释器/ipython 更改为 Enthought 发行版中的那个,或者如果我将 Cython 从 1.9.1 降级到 1.6,问题仍然存在。

C++ 中的内存泄漏 (?)

由于这看起来像是 C++ 代码中的内存泄漏(如果有其他可能的解释,请告诉我),我在 C++ 类的一些 C++ 测试代码上运行了 Valgrind,但没有发现任何问题。 (我不是 100% 确定它没有问题,因为我在 OSX Mountain Lion 上,尽管使用了最新的主干版本 Valgrind,但已知它有问题。我使用的是 OSX10.8 抑制文件,带有一个建议here 作为开始)。无论如何,C++ 类不使用 new/delete/malloc/free,所以应该没问题。

Cython 中的内存泄漏 (?)

我尝试在崩溃的 python 代码上运行 valgrind。除了上面提到的 OSX 抑制文件之外,我还添加了一个 python 抑制 file。 Valgrind 产生大量输出然后崩溃。在输出中没有对我的源代码的任何引用。这是犯罪的cython代码:

def split_props(np.ndarray[fptype, ndim=1, mode="c"] x,
                   np.ndarray[fptype, ndim=1, mode="c"] y,
                   np.ndarray[fptype, ndim=1, mode="c"] ylines):

cdef np.ndarray[fptype, ndim = 1, mode = "c"] areas = np.zeros((ylines.shape[0] + 1), dtype=np.float64, order="c")
cdef np.ndarray[fptype, ndim = 1, mode = "c"] static_moments_x = np.zeros((ylines.shape[0] + 1), dtype=np.float64, order="c")
cdef np.ndarray[fptype, ndim = 1, mode = "c"] inertia_moments_xx = np.zeros((ylines.shape[0] + 1), dtype=np.float64, order="c")

cdef SplitPolygon * SPINSTANCE = new SplitPolygon(100, 100)

SPINSTANCE.split_props(& x[0],  # = <fptype *> x.data
                         & y[0],
                         x.shape[0],
                         & ylines[0],
                         ylines.shape[0],
                         & areas[0],
                         & static_moments_x[0],
                         & inertia_moments_xx[0]
                         )
del SPINSTANCE
return areas, static_moments_x, inertia_moments_xx

上面,C++ 类是SplitPolygon。在python代码中,我从cython模块中只导入了上面的函数split_props,所以内存泄漏肯定在这部分代码或者C++代码中。而且python代码的功能和C++测试代码是一样的。

我在下面还报告了模块的另一部分,非常相似,但不会导致任何内存泄漏

def SplitCirc(np.ndarray[fptype, ndim=1, mode="c"] ycenters,
               np.ndarray[fptype, ndim=1, mode="c"] radii,
               np.ndarray[fptype, ndim=1, mode="c"] ylines):

cdef np.ndarray[fptype, ndim = 1, mode = "c"] areas = np.zeros((len(ylines) + 1), dtype=np.float64, order="c")
cdef np.ndarray[fptype, ndim = 1, mode = "c"] static_moments_x = np.zeros((len(ylines) + 1), dtype=np.float64, order="c")
cdef np.ndarray[fptype, ndim = 1, mode = "c"] inertia_moments_xx = np.zeros((len(ylines) + 1), dtype=np.float64, order="c")

split_circles(& ycenters[0], & radii[0], len(ycenters),
              & ylines[0], len(ylines),
              & areas[0], & static_moments_x[0], & inertia_moments_xx[0])
return areas, static_moments_x, inertia_moments_xx

现在,我真的被困在了这一点上。你觉得 cython 代码好看吗?是否有任何测试用例我可以编写代码来检查 C++ 类 SplitPolygon 是否真的没有泄漏?崩溃是否会因其他原因而发生?

【问题讨论】:

  • 这听起来不像是内存泄漏!听起来好像某些东西的析构函数取决于刚刚被破坏的东西,并且取决于东西被破坏的顺序,它有时有效,有时无效。
  • 内存泄漏不会导致崩溃;它只会浪费越来越多的内存。

标签: c++ python memory-leaks valgrind cython


【解决方案1】:

感谢 cmets。正如您所指出的,这不是内存泄漏。

问题在于数组x,y,ylines中传递的数据,这是错误的,因为它不遵守SplitPol()类的规范。

这导致SplitPols.split_props() 导致未定义的行为,在这种情况下是写入在调用SPINSTANCE.split_props() 时通过地址传递的3 个数组的边界之外。

这三个数组由 numpy 分配,其中 3 次调用 zeros()。损坏的内存就在它们附近,并且从运行到运行它可能属于一个关键的 Python 对象,导致或不导致段错误,从而看起来一切正常。

SplitPols.split_props() 代码返回正确的数据并没有帮助,除了破坏内存。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-12-05
    • 2018-03-03
    • 1970-01-01
    • 2016-01-27
    • 2010-11-11
    • 2017-02-18
    • 1970-01-01
    • 2010-11-13
    相关资源
    最近更新 更多