包含复杂类型的SWIG-ed C结构的引用计数似乎没有按预期工作

Question

我遇到了一个有趣的发现,涉及SWIG如何处理包含其他结构作为成员的C结构的引用计数.

我发现在我将数据从结构子成员存储到其他python对象(列表/ dicts)的情况下使用它们之前,我的python SWIG对象正在收集垃圾.经过一段时间的挖掘后,我发现SWIG-ed结构成员似乎没有自己的独立引用计数,即使解释器表明它们是"Swig Objects".因此,当我将结构子元素中的数据添加到我的列表时,python不知道我已经添加了对此数据的引用.

我创建了一个简单的案例来演示.我SWIG-ed以下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;
}

Answer 1

header正如已经指出的那样， and的 getter 返回的对象body基本上是一个轻量级代理对象，它保存着指向header/body内部的内存的指针struct。它不拥有该内存（它仍然由message对象本身或 C 库“拥有”，具体取决于您创建它的方式）并且它不是副本。

即使它是一个副本，您对 getter 的调用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"