项目中使用boost::property_tree::read_json引发coredump，几乎是稳定复现，而且每次core也基本都在同一个地方
但是，怎么看也不太像会出core的样子，所以就朝着内存写飞的方向排查了。搞了一上午的valgrind，最终还是报错
这个问题之前也遇到过，试了几次安装libc6-debug也没搞定。好吧，终于想起来请教大牛了，大牛反馈
这个不好搞；要hack valgrind的源码，改几个宏定义才能用；而且valgrind不好用，你用火焰图吧
大牛建议我使用jemalloc，并给了我几篇参考文档，但其实不是我想要的，我是想排查内存crash的问题，大牛建议我从gdb入手，便有了文章开头的直觉，怎么看也不像会有core的样子，而且还给大牛贴了core位置的代码。大牛提示：
我们之前遇到过一次json解析导致的core，查出来是我们的服务，同时用了rapidjson的so和静态链接的binary，然后两个版本不一致，导致core
于是，朝这个方向排查了一番，发现也没有这个问题，本地的so和最新的so也没有不一致。没辙了，死马当活马医吧，抱着试试看的态度google了一下，问题解决：
使用boost/property_tree/json_parser.hpp需要定义BOOST_SPIRIT_THREADSAFE宏。
程序是不会骗人的，多次core在同一个位置，基本就是这里有问题了，不妨搜一搜。虽然之前也遇到过，因为读了已经释放的内存导致core，人啊还是不能为经验所累。