我在
这样的行上有一个coredump进程// ptr is boost::shared_ptr<Whatever>
assert(ptr.unique())
即有两个shared_ptr引用相同的对象，但程序逻辑上需要独占所有权。它的逻辑问题，而不是内存损坏。
使用gdb我可以看到ptr中包含的指针的地址（例如0x001234567890），并验证它是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 ...
gdb中有一个命令find可以搜索指定区域的指定值，但它需要正确分配的内存区域。
有一个命令info mem显示有关内存区域的信息，但它对coredump不起作用。
还有其他方法可以找到存储此地址/值的方法吗？
答案 0 :(得分：1)
您应该考虑使用valgrind或某些address sanitizer（例如使用-fsanitize=address instrumentation option汇编到GCC）。它可能是帮助查找错误的最简单方法（假设您的错误可以重现）。
关于您的原始问题，最近的GDB extendable位于Python（可能还在Guile中）。您可以根据需要编写脚本。
您还可以在智能指针或指向对象的use_count字段上放置一个观察点（您可能需要禁用ASLR以简化调试）。
答案 1 :(得分：1)
要查找指向一块内存的指针，您可以使用 valgrind和gdb在一起。
然后从gdb，您可以使用monitor命令
(gdb) monitor who_points_at <addr> [<len>]
找到这些指针的位置。
所以，如果你对一段内存有2个引用，那么who_points_at 应该能够归还它们。
请注意who_points_at正在搜索任何“单词对齐”数据 指向范围[addr，addr + len（ 因此，您可能会发现更多例如整数可能“看起来”像 它指着这个记忆。
参见http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver 和 http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
了解更多信息。