源码版引擎 Test 版本 UStruct::SerializeExpr Crash

[FlyAndNotDown]

我们使用的是 4.25 源码版引擎，最近 MemReport -full 指令在 Test 版本下就用不了了，必现 Crash，挂的位置也很固定，会挂在 UStruct::SerializeExpr 中，大概的调用栈：

FPropertyProxyArchive::operator<<()
UStruct::SerializeExpr()
UStruct::Serialize()
UFunction::Serialize()
FArchiveCountMem::FArchiveCountMem()
UEngine::HandleObjCommand()
UEngine::Exec()

我查下来发现是 UnLua 插件导致的，我看 UnLua 为了替换蓝图调用做了一个字节码插入的操作：

在 UStruct::SerializeExpr() 中，有段 fallback 的逻辑：

不插入 Userdata 的时候这段逻辑会帮忙兜底，然鹅 UnLua 一旦插入 Userdata，也就是一个 FFunctionDesc 指针，在 EX_CallLua 和 EX_Return 间的字节码就不确定了，这样的话有可能在前面被处理成其他的逻辑，就导致了 Crash。

接着我测试了官方的 4.25 源码版和二进制版引擎，发现只有源码版会有问题。在非 Test/Shipping 版本下，EX_CallLua 和 EX_Return 间的字节码为空，就受上面那段 Fallback 的逻辑保护了，而二进制版引擎又没法打 Test 包，Shipping 又调不了 MemReport -full ......

所以只有源码版引擎 + Test 打包，才会 Crash，最终我在引擎中的处理策略是在 UStruct::SerializeExpr 加上 EX_CallLua 的处理逻辑来避免 Crash，但是作为插件这部分很难处理，想给你们反馈下这个问题，看下你们的意见。

[xuyanghuang-tencent]

挺巧的，早上刚看到这个issue就有同事反映了一样的问题。

这里UnLua为了优化函数调用的性能，直接把FunctionDesc/FSignatureDesc作为数据写到蓝图字节码里去了（省去后面的查找），是个比较tricky的做法，当时可能也没考虑到memreport的情况。如果能动UE源码的话，那直接加上EX_CallLua的处理逻辑是最科学的。次一点的方法则是使用额外的宏来控制，手动在性能和memreport上做取舍。

PS：目前同事也是参考了你的做法，感谢反馈

[FlyAndNotDown]

👌🏻

[xuyanghuang-tencent]

v2.2.0