Brush项目在macOS 15上的SIGBUS崩溃问题深度解析

问题现象

在macOS 15(代号Sequoia)系统上运行Brush项目的应用程序时，程序启动后会立即崩溃，并出现SIGBUS信号错误。错误信息显示为EXC_BAD_ACCESS (SIGBUS)，子类型为EXC_ARM_DA_ALIGN，发生在Image IO模块加载窗口图标的过程中。

初步分析

最初开发者误判这是图标文件对齐问题，认为macOS 15加强了对内存访问对齐的检查，特别是针对128位NEON向量指令的未对齐访问。这种假设源于：

1. 崩溃发生在Image IO读取插件初始化阶段
2. 错误类型明确指向ARM数据对齐异常
3. 使用include_bytes!宏嵌入的PNG图标可能只有1字节对齐

深入调查

经过更深入的调试和分析，发现真正的问题根源并非图标对齐问题：

1. 完全移除图标后，崩溃仍然发生
2. 尝试各种图标对齐修复方案均无效
3. 环境变量测试揭示关键线索

根本原因

问题实际上源于Homebrew环境变量污染导致的动态库加载冲突：

1. DYLD_LIBRARY_PATH指向Homebrew的ARM优化库
2. 这些库与系统库有不同的内存对齐要求
3. 库加载冲突表现为Image IO模块崩溃

解决方案

通过清理环境变量可以完美解决：

env DYLD_LIBRARY_PATH="" DYLD_FALLBACK_LIBRARY_PATH="" cargo run --bin brush_app --with-viewer

项目已添加Makefile封装这些命令：

# 带视图运行(自动清理macOS上的Homebrew路径)
make run-viewer

# 普通运行(自动清理macOS上的Homebrew路径)
make run-clean

技术启示

1. 环境变量污染：开发环境配置可能引入隐蔽问题
2. 错误定位陷阱：崩溃点不一定反映真正问题根源
3. ARM架构特性：苹果芯片对内存访问有更严格的要求
4. 构建系统设计：良好的构建系统应隔离环境依赖

最佳实践建议

1. 开发环境应保持干净，避免全局路径污染
2. 使用虚拟环境或容器隔离开发依赖
3. 构建系统应显式声明所有依赖
4. 跨平台项目需特别注意不同系统的库加载机制差异

这个问题展示了现代开发中环境配置复杂性的挑战，也提醒我们系统级错误的诊断需要全面考虑各种可能性。