5

我遇到了一个有趣的发现，与 SWIG 如何处理包含其他结构作为成员的 C 结构的引用计数有关。

我观察到，在我将结构子成员中的数据存储到其他 python 对象（lists/dicts）的情况下，我的 python SWIG 对象在我完成使用它们之前就被垃圾收集了。经过一番挖掘后，我发现 SWIG 结构成员似乎没有自己的独立引用计数，即使解释器表明它们是“Swig 对象”。因此，当我将结构子元素中的数据添加到我的列表中时，python 并不知道我已经添加了对该数据的引用。

我创建了一个简单的案例来演示。我 SWIG 编辑了以下 3 个结构：

SWIG-ed C 结构：

typedef struct
{
    unsigned long source;      
    unsigned long destination; 
} message_header;

typedef struct
{
    unsigned long data[120];    
} message_large_body;


typedef struct
{
    message_header       header;
    message_large_body   body;
} large_message;

然后，我创建了一个有点等价的 python 类来将行为与纯 SWIG-ed 解决方案进行比较。

有点等价的 Python 类

class pyLargeMessage(object):
    def __init__(self):
        self.header = bar.message_header()
        self.body = bar.message_large_body()

然后我在解释器中运行了以下测试。

Python 解释器结果

>>> y = pyLargeMessage()
>>> y
<__main__.pyLargeMessage object at 0x06C5E6B0>
>>> y.header
<Swig Object of type 'message_header *' at 0x06C5E700>
>>> sys.getrefcount(y.header)
3
>>> z = [y.header]
>>> sys.getrefcount(y.header)
3
>>> z += [y.header]
>>> sys.getrefcount(y.header)
4
>>>
>>> y = bar.large_message()
>>> y
<Swig Object of type 'large_message *' at 0x06C668E0>
>>> y.header
<Swig Object of type 'message_header *' at 0x06C66B60>
>>> sys.getrefcount(y.header)
1
>>> z = [y.header]
>>> sys.getrefcount(y.header)
1
>>> z += [y.header]
>>> sys.getrefcount(y.header)
1
>>>

Python 实现的行为符合我的预期，但纯 SWIG 实现却没有。有人可以解释这里发生了什么吗？

我已经多次阅读了 SWIG 文档的各个部分，但找不到任何似乎可以直接解释这一点的内容。我已经了解了很多关于事情如何运作的知识，但是对于上述现象，我找不到任何明确的解释/解决方法。

想了很久，一遍又一遍地重新阅读结构和类、代理类和结构数据成员部分并查看生成的包装器代码后，我仍然无法弄清楚为什么引用计数没有正常处理.

生成的 C 代码调用SWIG_NewPointerObj，最终（在大多数情况下）调用PyObject_New，而后者又应该（如 python 文档所述）返回一个新的引用。

为标头成员的 get-er 生成 SWIG 代码

SWIGINTERN PyObject *_wrap_large_message_header_get(PyObject *self, PyObject *args) {
  PyObject *resultobj = 0;
  large_message *arg1 = (large_message *) 0 ;
  void *argp1 = 0 ;
  int res1 = 0 ;
  message_header *result = 0 ;

  if (args && PyTuple_Check(args) && PyTuple_GET_SIZE(args) > 0) SWIG_fail;
  res1 = SWIG_ConvertPtr(self, &argp1,SWIGTYPE_p_large_message, 0 |  0 );
  if (!SWIG_IsOK(res1)) {
    SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "large_message_header_get" "', argument " "1"" of type '" "large_message *""'"); 
  }
  arg1 = (large_message *)(argp1);
  result = (message_header *)& ((arg1)->header);
  resultobj = SWIG_NewPointerObj(SWIG_as_voidptr(result), SWIGTYPE_p_message_header, 0 |  0 );
  return resultobj;
fail:
  return NULL;
}
4

1 回答 1

2

正如已经指出的，getter 返回的对象和header基本上body是一个轻量级代理对象，它为. 它不拥有该内存（它仍然由对象本身或 C 库“拥有”，具体取决于您创建它的方式）并且它不是副本。headerbodystructmessage

即使它是一个副本，您的调用sys.getrefcount也总是会返回 1 - 每次调用 getter 都会返回一个新副本。

从 Python 的角度来看，如果你想确保你永远不会有一个悬空指针，有两种方法可以修复它：

  1. headergetter 为/的副本返回一个代理，body它拥有它指向的内存。
  2. getter 返回一个代理，该代理持有对message自身的引用，因此即使message释放了它的引用计数也不能达到 0，而有代理对象引用它的一部分。

我已经整理了一个使用 SWIG 执行 #2 的示例。你的头文件保持不变，但是界面变成了：

%module test

%{
#include "test.h"
%}

%typemap(out) message_header * header %{
  // This expands to resultobj = SWIG_NewPointerObj(...) exactly as before:
  $result = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, 0);
  // This sets a reference to the parent object inside the child
  PyObject_SetAttrString($result, "_parent", obj0);
%}

%include "test.h"

这相当于说：

z = y.header
z._parent = y

在 Python 中。

有了这个，我们现在可以运行：

y = test.large_message()
print(sys.getrefcount(y))
print(y.header)
z = [y.header]
print(sys.getrefcount(y))
z += [y.header]
print(sys.getrefcount(y))

正如预期的那样，它显示了y随着创建的每个子对象代理而增加的引用计数。因此，他们引用的内存不能过早地释放（至少不能通过 SWIG）。

您可以使用以下方法使其更通用并将其应用于多个类型/成员%apply：

%module test

%{
#include "test.h"
%}

%typemap(out) SWIGTYPE * SUBOBJECT %{
  $result = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, 0);
  PyObject_SetAttrString($result, "_parent", obj0);
  assert(obj0);
  // hello world
%}

%apply SWIGTYPE * SUBOBJECT { message_header * header };
%apply SWIGTYPE * SUBOBJECT { message_large_body * body };

%include "test.h"
于 2012-12-23T12:46:54.980 回答