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

Question

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

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

我创建了一个简单的案例来演示。我痛饮了以下 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 文档的各个部分，但找不到任何似乎可以直接解释这一点的内容。我已经了解了很多关于事物如何运作的知识，但我找不到针对上述现象的任何明确解释/解决方法。

想了半天，重新看了Structures and Classes，Proxy classes和 Structure Data Members一遍又一遍地查看生成的包装器代码，我仍然无法弄清楚为什么引用计数没有正常处理。

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

为 header 成员的 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 和 body 的 getter 返回的对象基本上是一个轻量级代理对象，它包含指向 header 的内存指针/body 在 struct 中。它不拥有该内存(它仍然由 message 对象本身或 C 库“拥有”，具体取决于您如何创建它)并且它不是副本。

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

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

1. getter 返回 header/body 副本的代理，它拥有它指向的内存。
2. getter 返回一个代理，它持有对 message 本身的引用，因此即使 message 被释放，它的 refcount 也不会在有代理的情况下达到 0引用其中一部分的对象。

我整理了一个使用 SWIG 执行 #2 的示例。你的头文件保持不变，但是接口(interface)变成了:

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