spdlog异步日志中source_loc内存问题的分析与解决

问题背景

在使用spdlog日志库时，开发者Ducatel遇到了一个异步日志记录下的内存问题。当使用异步日志记录器(async logger)配合rotating_file sink和source_loc功能时，输出的日志中文件名和函数名出现了乱码现象，而同步日志记录则表现正常。

问题现象

在异步日志模式下，日志输出中本应显示文件名和函数名的位置出现了乱码字符，如"ùùùùùù"和"µµµµµµµµ"等。而在同步日志模式下，这些信息能够正确显示为实际的文件路径和函数名。

问题分析

这个问题本质上是一个内存生命周期管理问题。spdlog的source_loc结构体默认情况下只保存了指向字符串的指针，而没有进行深拷贝。当使用异步日志时，日志消息会被放入队列，在另一个线程中被处理。此时原始字符串可能已经超出了作用域或被释放，导致指针失效，从而读取到无效内存。

技术细节

spdlog的source_loc结构体默认实现非常简单，它只保存了三个成员：

• 文件名指针
• 行号
• 函数名指针

当这些指针被传递给异步日志器时，原始字符串可能已经失效，但指针仍然被后续的日志处理线程使用，导致内存访问违规。

解决方案

开发者提出了一个修改版的source_loc实现，通过深拷贝来确保字符串数据的生命周期足够长。这个方案的关键点包括：

1. 在构造函数中进行字符串的深拷贝
2. 实现拷贝构造函数和赋值运算符
3. 在析构函数中释放分配的内存

这种实现虽然解决了问题，但增加了内存管理的复杂性。根据spdlog维护者的意见，这种改动会增加代码复杂度，而source_loc的这种高级用法并不是常见需求。

实际应用建议

对于大多数开发者，建议采用以下替代方案：

1. 将文件信息和函数信息直接放入日志消息体中，而不是依赖source_loc
2. 如果必须使用source_loc，确保相关字符串的生命周期足够长
3. 考虑使用静态字符串或字符串字面量作为source_loc参数

总结

spdlog的异步日志功能在性能上有明显优势，但在使用source_loc这类功能时需要特别注意内存管理问题。理解日志记录过程中数据的生命周期对于正确使用高级日志功能至关重要。对于大多数场景，简单的日志消息格式化已经足够，而无需过度依赖source_loc这样的高级特性。

这个案例也提醒我们，在使用任何日志库时，都应该充分理解其内部工作机制，特别是在涉及多线程和异步操作时，要特别注意数据生命周期的管理。