I have a process coredump on a line like
// ptr is boost::shared_ptr<Whatever>
assert(ptr.unique())
That is there are two shared_ptr referencing same object, but program logically expects exclusive ownership. It's logic problem, not memory corruption.
Using gdb I can see address (e.g. 0x001234567890) of pointer, contained in ptr and verify that it's use_count == 2.
Using hexdump on something like it I can easily find other occurrences:
$ 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 ...
There is a command find in gdb than can search specified region for specified value, but it need correct allocated memory region.
There is a command info mem which shows info about memory regions, but it doesn't work for coredumps.
Are there other ways to find, where this address/value is stored?
To find the pointers pointing at a piece of memory, you can use valgrind and gdb together.
Then from gdb, you can use the monitor command
(gdb) monitor who_points_at <addr> [<len>]
to find where are these pointers.
So, if you have 2 references to a piece of memory, who_points_at should be able to return them.
Note that who_points_at is searching for any 'word aligned' data that points at the range [addr, addr + len( So, you might find more occurences as e.g. an integer might 'look' like it is pointing at this memory.
See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver and http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
for more info.