項目中使用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，人啊還是不能爲經驗所累。