AIX平台使用XLClang++时__cxa_end_catch崩溃问题排查

代码层面的可能问题排查 #

虽然你移除std::exception_ptr后问题依然存在，但仍可排查几个潜在代码问题：

• 异常对象生命周期管理：若循环创建std::invalid_argument时，存在未正确销毁异常对象的场景（比如在异常处理流程外持有异常引用、重复捕获同一异常实例），可能触发未定义行为。但你提到简化到仅循环创建该对象就出问题，这种可能性极低。
• 多线程异常处理安全性：编译时指定了-D_REENTRANT，需确保多线程场景下异常处理流程无非标准操作。C++11标准要求std::exception_ptr线程安全，但若代码存在手动操作异常栈的行为，可能引发问题。
• 32位程序内存限制：AIX 32位程序默认MAXDATA值较小，即使设置到0x80000000（2GB），内存泄漏也会快速耗尽资源，但简化测试场景的泄漏更可能指向STL实现问题。

编译器/工具链缺陷的可能性 #

结合测试结果，工具链缺陷的概率极高：

• STL异常类内存泄漏：仅循环创建std::invalid_argument就出现内存耗尽、段错误，说明该异常类的构造/析构逻辑存在泄漏，属于XLClang++的STL实现问题。
• std::exception_ptr实现问题：最初引入该特性后触发崩溃，开启MALLOCTYPE=debug MALLOCDEBUG=postfree_checking时段错误指向__cxa_end_catch函数，可能是exception_ptr管理异常对象内存时存在越界或重复释放问题，调试malloc工具放大了该问题。
• 版本升级未修复缺陷：升级到XLClang++ 16.01.0000.0020后问题依旧，说明该版本STL实现仍存在相关缺陷。

建议排查步骤 #

1. 编写最小复现代码：用仅包含循环创建并销毁std::invalid_argument的代码，确认内存泄漏是否稳定复现，方便定位根源：

   #include <stdexcept>
   int main() {
       while (true) {
           std::invalid_argument e("test");
       }
       return 0;
   }
   

2. 调整编译选项测试：尝试关闭优化（-O0）、移除-qroconst等选项，排查是否为优化导致的STL代码异常。
3. 提交IBM官方支持：由于最小复现场景下问题稳定存在，且版本升级未修复，建议将复现代码、编译命令、环境信息提交给IBM技术支持，确认是否为已知缺陷或需修复的bug。

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