PhysX物理引擎中共享形状导致的内存崩溃问题分析

问题背景

在使用NVIDIA PhysX 5.4.2物理引擎开发开放世界游戏时，开发团队遇到了一个频繁发生的崩溃问题。崩溃主要发生在AABBPruner模块中，表现为内存访问违规，且崩溃点分布在多个不同的调用栈上，包括addActors、removeActors以及射线检测等涉及Pruner的操作。

问题现象

崩溃发生时通常伴随着以下特征：

1. 内存分配器出现异常
2. 调用栈显示在PxArray的重新分配过程中失败
3. 崩溃可能发生在场景查询构建步骤中
4. 使用Checked构建时没有触发任何断言或警告

问题根源

经过深入排查，发现问题根源在于同一个形状被多次附加到同一个角色上。具体场景是：

1. 开发团队实现了一个形状共享池，允许多个角色共享相同的碰撞形状
2. 由于美术资源中的错误，某些碰撞体形状被意外重复
3. 在角色创建过程中，相同的形状指针被多次调用attachShape附加到同一个角色上
4. 当这些角色被释放时，形状的引用计数出现异常，导致内存损坏

技术分析

PhysX引擎对形状共享有一定限制：

• 同一个形状可以附加到不同角色上（前提是形状没有设置独占标志）
• 但同一个形状不能多次附加到同一个角色上

在Checked构建中，这一限制没有被明确检测和报告，导致问题难以诊断。当这种情况发生时，形状的引用计数管理会出现问题，可能在释放时导致双重释放或内存越界。

解决方案

1. 立即解决方案：

   • 检查并确保每个形状只附加到每个角色一次
   • 在形状共享池中添加重复附加检测逻辑

2. 长期改进：

   • 开发团队已确认将在下一个PhysX版本中添加Checked构建的检测逻辑，当检测到同一形状被多次附加到同一角色时会报告错误
   • 建议在使用形状共享池时实现额外的引用计数跟踪机制

最佳实践建议

1. 形状管理：

   • 实现严格的形状附加日志记录
   • 在调试版本中添加附加次数验证
   • 考虑使用包装器管理形状共享

2. 内存安全：

   • 使用内存调试工具监控引用计数
   • 定期验证形状引用的一致性

3. 场景管理：

   • 分批处理角色添加/移除时注意形状状态
   • 实现场景加载时的形状完整性检查

总结

这个案例展示了物理引擎使用中一个容易被忽视但危害巨大的问题。形状共享虽然能提高性能，但需要严格的管理机制。PhysX团队已意识到这一问题并计划在后续版本中改进错误检测机制。对于开发者而言，在实现类似形状共享池这样的优化时，应当特别注意引用管理和边界条件检查，以避免类似的内存安全问题。