UE4SS项目中的Lua脚本UFunction返回值内存安全问题分析

UE4SS项目中的Lua脚本UFunction返回值内存安全问题分析

【免费下载链接】RE-UE4SS Injectable LUA scripting system, SDK generator, live property editor and other dumping utilities for UE4/5 games 项目地址: https://gitcode.com/gh_mirrors/re/RE-UE4SS

问题概述

在UE4SS项目中，当Lua脚本调用Unreal Engine的UFunction时，返回值的处理存在严重的内存安全问题。具体表现为返回的FString等对象会出现悬垂指针问题，导致后续访问时数据损坏或程序崩溃。这个问题源于对栈上临时对象的不当引用，以及缺乏正确的内存管理机制。

技术背景

UE4SS项目通过Lua脚本扩展Unreal Engine的功能，其中涉及到C++与Lua之间的数据交互。当Lua调用UFunction时，需要处理Unreal Engine对象在两种语言环境间的传递和生命周期管理。

在Unreal Engine中，FString等对象使用自定义的内存管理机制，通常通过TArray实现字符串存储。当这些对象作为UFunction的返回值时，需要特别注意其生命周期和内存所有权。

问题详细分析

栈对象引用问题

在call_ufunction_from_lua函数中，DynamicUnrealFunctionData结构体被创建在栈上，用于临时存储函数参数和返回值。问题出现在处理返回值时：

1. 返回值指针直接指向栈上的dynamic_unreal_function_data.data区域
2. 这些指针被直接赋给Lua对象的m_cpp_object成员
3. 当函数返回后，栈空间被释放，但这些指针仍然被Lua对象持有

内存泄漏问题

除了悬垂指针问题外，还存在内存泄漏：

1. FString内部的TArray缓冲区没有被正确释放
2. 系统错误地假设Unreal Engine会负责这些内存的释放
3. 实际上这些临时对象需要由Lua环境管理其生命周期

影响范围

这个问题不仅影响FString类型，还会影响所有通过栈返回的结构体类型，包括：

1. 基本类型的返回值
2. 结构体类型的返回值
3. UFunction的out参数

解决方案探讨

临时对象管理

正确的解决方案应该考虑以下几点：

1. 对于返回的FString等对象，应该创建堆上的副本
2. 需要实现适当的拷贝构造函数或克隆方法
3. 确保Lua对象拥有这些堆上对象的所有权

内存释放机制

针对不同类型，需要不同的内存管理策略：

1. 对于FString等简单类型，可以直接在Lua对象析构时调用其析构函数
2. 对于复杂类型，可能需要调用FProperty::DestroyValue
3. 需要考虑是否使用引用计数或智能指针来管理内存

类型区分处理

解决方案需要区分不同类型的处理方式：

1. 真正的远程对象（由Unreal Engine管理）
2. 临时创建的本地对象（由Lua环境管理）
3. 简单值类型（可以直接拷贝）

实现建议

对象包装策略

建议采用以下包装策略：

1. 为所有返回值创建LocalObject包装
2. 实现适当的拷贝语义
3. 在Lua对象析构时正确释放资源

具体实现步骤

1. 修改m_property_value_pushers实现，为返回值创建堆上副本
2. 完善Lua类型系统，区分远程对象和本地副本
3. 实现统一的资源释放接口
4. 为不同类型实现特定的拷贝和析构逻辑

结论

UE4SS项目中Lua脚本调用UFunction的返回值处理存在严重的内存安全问题，需要系统性地重构对象传递和内存管理机制。正确的解决方案应该考虑不同类型对象的生命周期管理，确保内存安全的同时避免资源泄漏。这个问题也提醒我们在跨语言交互时需要特别注意对象所有权和生命周期的管理。

【免费下载链接】RE-UE4SS Injectable LUA scripting system, SDK generator, live property editor and other dumping utilities for UE4/5 games 项目地址: https://gitcode.com/gh_mirrors/re/RE-UE4SS