Boost add_file_log多线程下rotation_size触发崩溃的排查方法咨询

• 确认日志库的线程安全配置
  先检查你使用的日志库是否默认支持多线程场景下的文件轮转。不少日志库需要显式启用线程安全选项，比如指定异步日志器、绑定线程池，或者在初始化add_file_log时添加线程安全标记。如果漏开这个配置，多线程写日志时会触发竞态条件，导致轮转操作崩溃。

• 临时添加线程同步测试
  在所有写日志的代码块外围加全局互斥锁（比如C++的std::mutex），强制同一时间只有一个线程写日志。如果加锁后崩溃消失，说明核心问题是多线程并发写日志时的竞态冲突，重点排查日志库的线程安全配置是否正确。

• 生成并分析核心转储
  Linux下执行ulimit -c unlimited开启核心转储，Windows在调试器中配置生成dump文件。崩溃后用gdb（Linux）或WinDbg（Windows）加载核心文件，查看栈回溯信息，定位崩溃的具体函数——比如是在文件重命名、关闭旧日志文件，还是写入新文件时出错，这能直接缩小问题范围。

• 添加轮转调试日志
  如果日志库支持轮转回调函数，在回调里打印当前线程ID、日志文件大小、文件路径等信息；如果没有回调，就在靠近add_file_log的地方手动加调试输出，记录轮转前后的状态。重点看崩溃前是否有多个线程同时触发轮转操作，或者文件状态异常（比如文件被意外删除、权限变更）。

• 排除文件系统影响
  把日志输出路径切换到本地磁盘（如果之前用的是NFS等网络文件系统），因为部分网络文件系统不支持原子重命名操作，多线程下同时修改文件会导致状态混乱。如果切换到本地磁盘后问题消失，说明是文件系统的兼容性问题。

• 升级日志库版本
  排查你使用的日志库是否有已知的多线程轮转bug，比如旧版本的日志库曾出现过多线程下轮转时的空指针问题。升级到最新稳定版，看是否能直接解决问题。

• 编写最小复现用例
  剥离业务代码，写一个仅包含日志初始化和多线程写日志的最小程序。如果这个小程序能复现崩溃，说明是日志配置或库本身的问题；如果不能，那大概率是业务代码中的其他线程安全问题（比如内存越界、资源冲突）影响了日志模块。

• 检查资源泄漏
  用lsof（Linux）或Process Explorer（Windows）查看进程的文件描述符数量，确认是否存在文件描述符泄漏。如果打开的文件数超出系统限制，轮转时无法创建新日志文件，会直接引发崩溃。

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