GDSDecomp项目中的纹理导出崩溃问题分析与解决方案

GDSDecomp项目中的纹理导出崩溃问题分析与解决方案

gdsdecomp Godot reverse engineering tools 项目地址: https://gitcode.com/gh_mirrors/gd/gdsdecomp

问题背景

在GDSDecomp项目中，用户报告了一个在处理Psychopomp Gold游戏资源时遇到的严重崩溃问题。该问题主要出现在尝试导出特定纹理资源时，系统会抛出"free(): corrupted unsorted chunks"错误并终止程序。

崩溃现象分析

崩溃发生时，调用栈显示问题出现在纹理转换流程中，具体是在ImageExporter::_convert_tex函数处理res://Sprites/Items/ParagonKeyAnim.png纹理资源时。该纹理的原始尺寸为381×127像素，但在处理过程中被填充为384×128像素（因为BC压缩格式要求尺寸必须是4的倍数）。

通过Valgrind内存检查工具的分析，发现存在无效的内存写入操作，这表明程序在解压缩纹理数据时可能越界访问了内存区域。

根本原因

深入分析后发现，问题的根源在于Godot引擎的BC解压缩模块对mipmap处理的缺陷：

1. 当纹理尺寸不是4的倍数时，引擎会自动填充尺寸
2. 但对于mipmap链中的最小mipmap（1×1像素），这个填充逻辑没有正确处理
3. 导致在解压缩过程中写入超出分配内存范围的数据
4. 最终引发内存损坏和后续的double-free错误

解决方案

针对这个问题，开发团队采取了两种解决方案：

1. 临时解决方案：在导出纹理前显式清除mipmap数据。由于导出功能实际上并不需要使用mipmap，这种方法简单有效且不会影响最终结果。

2. 长期解决方案：向Godot引擎提交了修复补丁，确保BC解压缩模块正确处理所有mipmap级别的尺寸对齐问题。

技术启示

这个问题给我们几个重要的技术启示：

1. 压缩纹理处理需要特别注意尺寸对齐要求
2. mipmap链中的每个级别都需要单独验证和处理
3. 内存管理错误往往表现为后续操作中的崩溃，需要仔细追溯根源
4. 跨平台开发时要注意不同系统内存管理实现的差异

结论

通过这次问题的分析和解决，不仅修复了GDSDecomp工具中的特定崩溃问题，也为处理类似压缩纹理资源提供了宝贵经验。开发者在使用这类工具时，如果遇到类似问题，可以考虑检查纹理尺寸是否符合压缩格式要求，或者暂时禁用mipmap功能作为临时解决方案。

gdsdecomp Godot reverse engineering tools 项目地址: https://gitcode.com/gh_mirrors/gd/gdsdecomp