boost::make_shared在64位系统崩溃，替换为new/std::shared_ptr可正常运行

问题背景 #

原有32位C++程序迁移到64位后，使用boost::make_shared<MyClass>()创建智能指针时频繁触发SIGSEGV/SIGBUS崩溃，但改用boost::shared_ptr<MyClass>(new MyClass())或替换为std::shared_ptr后恢复正常，32位环境无异常，升级Boost版本也无法解决。

核心原因推测 #

• 内存对齐不匹配：64位系统对内存对齐的要求远高于32位。boost::make_shared会将对象实例与引用计数结构体分配在同一块连续内存中，若MyClass存在自定义对齐要求（如alignas(16)或编译器特定的对齐属性），而Boost的内存分配逻辑未满足该对齐标准，就会触发对齐错误（SIGBUS的典型诱因）。直接用new时，编译器会严格按MyClass的对齐要求分配内存，而std::make_shared的内存对齐实现更贴合64位系统规范。
• Boost的64位编译/ABI兼容性问题：若Boost库编译时未针对64位架构配置（如未指定address-model=64），或编译选项（编译器版本、优化级别、C++标准）与项目不一致，会导致二进制接口不兼容，进而在make_shared的内存分配逻辑中出现崩溃。即使升级到最新Boost版本，若编译配置仍不匹配，问题依然存在。
• 未定义行为的暴露：32位系统的内存地址空间布局和访问特性可能掩盖了代码中的未定义行为（如MyClass内部的数组越界、未初始化成员访问）。64位系统下内存布局更严格，boost::make_shared的紧凑内存分配方式会让这类问题直接触发崩溃，而new的内存分配位置不同，暂时未触发异常。

排查与修复建议 #

• 检查类的对齐设置：查看MyClass是否有自定义对齐声明，确认Boost分配器是否支持该对齐。可尝试显式指定对齐参数给boost::make_shared，或调整类的对齐要求至Boost分配器支持的范围。
• 重新编译Boost库：确保Boost以64位模式编译，编译选项与项目完全一致。使用b2编译时添加address-model=64参数，同时指定与项目相同的编译器、C++标准版本及优化级别。
• 检测未定义行为：使用Valgrind或AddressSanitizer等内存检测工具扫描代码，定位并修复内存越界、未初始化变量等问题——这些问题是导致64位下崩溃的潜在根源。
• 临时替代方案：若暂时无法定位根本原因，可继续使用boost::shared_ptr<T>(new T())或全面替换为std::shared_ptr，这两种方式在64位环境下的内存处理逻辑更稳定。

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