Loading... 这个问题比较复杂，简单的一个 rapidjson 的 Parse 逻辑。现象来看却产生rapidjson allocator未定义的core dump，经过了多方排查，数据是否为非法json，是否存在非法内存访问等都没有发现问题。  最后经过仔细排查堆栈发现从一个版本的rapidjson跳转到了另一个版本的rapidjson，两个版本的文件路径不一致。  也就是说，我们本来初始化的是 A 版本的 rapidjson，对应的内存布局是存在的，但是突然跳转到另一个版本，那边实际上没有初始化，所以就出现了这种不可预知的行为。 而解决这个问题的方法也是想了好几种去尝试，一个是更改掉从别的框架引入的rapidjson的命名空间，然后发现对应框架也有用到所以不太可行，改自己模块的版本也不太可行，因为也是被其他模块引用了，而且使用了新版本的特性，最后是通过编译单元隔离的方法进行的解决。 因为C++编译单元是以 cpp/cc/cxx 为单位变成目标文件的，所以我们只要保证单个 cpp/cc/cxx 文件不存在两个版本的rapidjson引入，就不会产生符号污染。 也就是说，我们可以定义一个头文件定义对应的rapidjson解析函数，但是不在头文件引入rapidjson，而是在对应的实现文件，也就是 cpp/cc/cxx 中引入，这样就能保证不会互相污染。 然后在目标文件产生后的链接过程，因为每个目标文件符号会进行混淆，所以在这一步的符号也不会冲突，那么最终就能保证不会出现乱调用的情况了。 Last modification：August 1, 2025 © Allow specification reprint Support Appreciate the author AliPayWeChat Like 1 如果觉得我的文章对你有用，请随意赞赏
