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

Question

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

我观察到，在我将结构子成员中的数据存储到其他python对象（list/dict）中的情况下，python SWIG对象在使用它们之前就被垃圾回收了。经过一番深入研究，我发现SWIG-ed结构成员似乎没有自己独立的引用计数，即使解释者指出它们是“SWIG对象”。因此，当我将structure子元素中的数据添加到列表中时，python不知道我添加了对该数据的引用。在

我创建了一个简单的案例来演示。我用了以下三种结构：

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类，将行为与纯swiged解决方案进行比较。在

有点类似的Python类

^{pr2}$

然后我在翻译程序中运行以下测试。在

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文档的各个部分，但是没有找到任何可以直接解释这一点的东西。我学到了很多东西是如何工作的，但我找不到任何关于上述现象的明确解释/解决办法。在

经过长时间的思考，反复阅读结构和类、Proxy classes和Structure Data Members部分并查看生成的包装器代码后，我仍然无法理解为什么引用计数不能正常处理。在

生成的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

如前所述，getter为header和body返回的对象基本上是一个轻量级代理对象，它在struct中为header/body保存一个指向内存的指针。它不拥有内存（它仍然是由message对象本身或C库“拥有”的，这取决于您如何创建它），而且它不是一个副本。在

即使它是一个副本，对sys.getrefcount的调用仍将始终返回1—每次对getter的调用都将返回一个新副本。在

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

1. getter返回header/body副本的代理，该副本拥有它所指向的内存。在
2. getter返回一个代理，该代理保存对message本身的引用，因此即使释放了message，它的refcount也不能达到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"

这相当于说：

^{pr2}$

在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"