The "find" command returns incorrect addresses for the matches that it found. For example: Breakpoint 1, main () at try.c:28 28 r.m_socket = 0; (gdb) info shared From To Syms Read Shared Object Library 0xb7fe3830 0xb7ff969f Yes (*) /lib/ld-linux.so.2 0xb7ee59c0 0xb7fa8738 Yes /usr/local/lib/libcrypto.so.0.9.8 0xb7d66930 0xb7e5ad6c Yes (*) /lib/tls/i686/cmov/libc.so.6 0xb7d4ba40 0xb7d4c988 Yes (*) /lib/tls/i686/cmov/libdl.so.2 (*): Shared library is missing debugging information. (gdb) find 0xb7ee59c0, 0xb7fa8738, (int) 0x6a09e667 0xb7ef30b6 <sha512_block_data_order+9222> 1 pattern found. (gdb) x 0xb7ef30b6 0xb7ef30b6 <sha512_block_data_order+9222>: 0xc744247c (gdb) disass SHA256_Init Dump of assembler code for function SHA256_Init: 0xb7eef230 <SHA256_Init+0>: mov 0x4(%esp),%eax 0xb7eef234 <SHA256_Init+4>: movl $0x6a09e667,(%eax) 0xb7eef23a <SHA256_Init+10>: movl $0xbb67ae85,0x4(%eax) 0xb7eef241 <SHA256_Init+17>: movl $0x3c6ef372,0x8(%eax) 0xb7eef248 <SHA256_Init+24>: movl $0xa54ff53a,0xc(%eax) 0xb7eef24f <SHA256_Init+31>: movl $0x510e527f,0x10(%eax) 0xb7eef256 <SHA256_Init+38>: movl $0x9b05688c,0x14(%eax) 0xb7eef25d <SHA256_Init+45>: movl $0x1f83d9ab,0x18(%eax) 0xb7eef264 <SHA256_Init+52>: movl $0x5be0cd19,0x1c(%eax) 0xb7eef26b <SHA256_Init+59>: movl $0x0,0x20(%eax) 0xb7eef272 <SHA256_Init+66>: movl $0x0,0x24(%eax) 0xb7eef279 <SHA256_Init+73>: movl $0x0,0x68(%eax) 0xb7eef280 <SHA256_Init+80>: movl $0x20,0x6c(%eax) 0xb7eef287 <SHA256_Init+87>: mov $0x1,%eax 0xb7eef28c <SHA256_Init+92>: ret End of assembler dump. (gdb) The address it returned doesn't match reality at all.
Created attachment 6457 [details] proposed patch for GDB find command returning bogus results Proposed patch for GDB find command returning bogus results. The patch is based on GDB version 7.0.1, but I think there is only one line changed in the newest version (as of June 18, 2012). The fix consists of rewriting simple_search_memory() in gdb/target.c to be simpler and address at least a couple of issues.
See also bug 17756. I couldn't find a way to reproduce this failure though.
Couldn't reproduce, and we even added a unit-test to try to catch this problem.
I definitely cannot reproduce it today, with gdb 8.3 on a 64 bit machine. I note that it was a 32 bit build with gdb 7.0 when I reported this bug. I'm not sure I can recreate that build environment at this point anyway.