Python print()破坏ctypes分配内存 字节传参差异问题排查

这是ctypes传参场景下典型的临时对象生命周期不匹配导致的悬空指针问题，不存在Python越权修改C++内存的情况，问题出在C接口实现和Python侧传参的生命周期管理漏洞上。

两个示例的运行差异完全来自bytes对象的生命周期区别：

• 正常运行的版本中，bytes('my_name', 'utf-8')生成的bytes对象赋值给了全局作用域的name变量，只要该变量不被主动删除、不离开作用域，其内部存储字符串的内存就会一直被Python标记为占用状态，C++侧存储的指针始终指向合法内存，读取值自然稳定。
• 故障版本中，bytes(name, 'utf-8')是__init__方法内生成的临时对象，传入MyClass_Open后没有任何Python变量持有它的引用，__init__执行结束后该临时对象会被Python垃圾回收器标记为可回收，对应内存会交还给Python内存分配器等待复用。后续执行print、标准输出写入等操作时，Python会申请这块已经释放的内存存放临时数据，就出现了你观测到的现象：Name指针的地址完全没变，但存储的内容变成了print的参数、或是无缓冲模式下被清空为空白——本质是C++侧的Name指针指向了已经被释放、随时可能被覆写的野内存。

核心C端代码bug：当前MyClass_Open的实现是直接把传入的const char*指针赋值给了类成员Name，没有对字符串内容做拷贝。ctypes将bytes对象转换为C字符串传参时，仅保证指针在C函数调用期间有效，不会承诺函数返回后该指针指向的内存仍然合法。

1. 根因修复（必须做） #

在C/C++接口层解决内存所有权问题：所有外部传入的字符串参数，如果需要在函数返回后长期持有，必须自行分配内存拷贝字符串内容，禁止直接存储外部传入的指针。
参考修复代码：

// 错误实现（当前版本）
void MyClass_Open(MyClass* obj, const char* name) {
    obj->Name = name; // 直接存储外部传入指针，生命周期不受自身管控
}

// 正确实现
void MyClass_Open(MyClass* obj, const char* name) {
    // 先释放之前持有的Name内存，避免内存泄漏
    if (obj->Name) free(obj->Name);
    obj->Name = strdup(name); // 自行分配内存拷贝字符串，生命周期自主管控
}

// 配套在对象销毁接口中释放拷贝的字符串内存
void MyClass_Close(MyClass* obj) {
    if (obj->Name) free(obj->Name);
    // 其余对象销毁逻辑
}

2. Python侧临时规避方案（仅验证用，不推荐长期使用） #

如果暂时无法修改C端代码，必须保证传给MyClass_Open的bytes对象在整个C++对象生命周期内被Python持有引用，避免被垃圾回收。例如将传入的bytes存为Python类的实例属性：

class MyBreakingClass():
    def __init__(self, name):
        # 将bytes存为实例属性，长期持有引用
        self._name_holder = bytes(name, 'utf-8')
        self.obj = lib.MyClass_Open(self._name_holder)

    def get_name(self):
        return lib.MyClass_GetName(self.obj).decode('utf-8')

该方案鲁棒性极差，一旦后续代码漏持引用就会复现野指针问题，仅能作为临时验证手段。

3. 调试验证方法 #

• 可以在Python侧传参后通过ctypes.addressof获取传入字符串的内存地址，和C++侧打印的Name地址做比对，在执行一次print操作后检查该地址对应的Python对象引用计数，就能观测到临时bytes对象已经被回收。
• 用valgrind运行对应Python脚本，会直接报Invalid read of size 1类的野指针读取错误，可直接定位到GetName读取已释放内存的问题点。

内容的提问来源于stack exchange，提问作者TJ Scherer