的整個存儲值我有一個對準的處理核心轉儲像GDB:找到轉儲
// ptr is boost::shared_ptr<Whatever>
assert(ptr.unique())
也就是說有兩個shared_ptr
引用同一個對象,但程序邏輯預計獨佔所有權。這是邏輯問題,而不是內存損壞。
使用gdb我可以看到指針的地址(例如0x0),包含在ptr
中並驗證它是use_count == 2
。
使用的類似的東西hexdump都我可以很容易地找到其他事件:
$ xxd core2 | fgrep '9078 5634 1200'
114e3e1e0109c 002c 307f 0000 9078 5634 1200 0000 ...
15b8b2ba000d7 ffa2 307f 0000 9078 5634 1200 0000 ...
1618b644000e7 7fa3 307f 0000 9078 5634 1200 0000 ...
有一個命令find
在gdb比可以搜索特定區域的規定值,但它需要更正分配的內存區域。
有一個命令info mem
它顯示有關內存區域的信息,但它不適用於coredumps。
有沒有其他的方法可以找到這個地址/值的存儲位置?
對不起,誤導,但它不是一個內存問題。 它看ms GDB提供的一切GDB提供的一切,因此它不是一個答案。 Watchpoint可以解決這個問題,但是在運行時有很多動態創建的指針,並且問題很少出現。 – MadRunner