GDB strace显示它试图在无效地址处进行ptrace

Question

I encountered such error when executing ni command during gdb debugging:

Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x3ac706a: Input/output error.

0xf6fa4771 in siglongjmp () from /lib/libc.so.6

To investigate what problem gdb meets with I strace gdb and get such output:

rt_sigprocmask(SIG_BLOCK, NULL, [RT_1], 8) = 0
ptrace(PTRACE_PEEKTEXT, 651, 0xcc4fdf60, [0x1cc4fe470]) = 0
ptrace(PTRACE_PEEKTEXT, 651, 0xcc4fe480, [0x3ac706a4506fa1d]) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_1], 8) = 0
…
...
rt_sigprocmask(SIG_BLOCK, NULL, [RT_1], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_1], 8) = 0
ptrace(PTRACE_GETREGS, 27781, 0, 0x7fff8990e8b0) = 0
ptrace(PTRACE_PEEKTEXT, 27781, 0x3ac7068, [0x28b]) = -1 EIO (Input/output error)
ptrace(PTRACE_PEEKTEXT, 27781, 0x3ac7068, [0x28b]) = -1 EIO (Input/output error)

It implies that gdb first ptrace at memory address 0xcc4fe480 and gets value 0x3ac706a4506fa1d (actually a 8-byte value 0x03ac706a4506fa1d ). Later it gets an aligned address 0x3ac7068 from the first 4 bytes of that value, which is an invalid address and causes gdb fails to ptrace.

Content of /proc/[pid]/maps:

cbce2000-cc353000 r-xp 00000000 08:03 295479 xxx.so
cc353000-cc3f0000 r--p 00670000 08:03 295479 xxx.so
cc3f0000-cc3f6000 rw-p 0070d000 08:03 295479 xxx.so
cc3f6000-cc3fe000 rw-p cc3f6000 00:00 0
cc3fe000-cc3ff000 ---p cc3fe000 00:00 0
cc3ff000-cc4ff000 rwxp cc3ff000 00:00 0
cc4ff000-cc500000 ---p cc4ff000 00:00 0

cc500000-cc600000 rwxp cc500000 00:00 0
cc62d000-cc673000 r-xp 00000000 08:03 295545 yyy.so
cc673000-cc674000 ---p 00046000 08:03 295545 yyy.so
cc674000-cc675000 r--p 00046000 08:03 295545 yyy.so
cc675000-cc676000 rw-p 00047000 08:03 295545 yyy.so

It shows that address 0xcc4fe480 is from the section with bold font above. This section is not related to any .so or bin file.

This question is actually related to another question http://stackoverflow.com/questions/9564417/gdb-cant-insert-internal-breakpoint , which has not been resolved yet. I found these problems during the investigation of previous issue.

I have 3 questions here:
1. Take a look at strace output for ptrace here:
ptrace(PTRACE_PEEKTEXT, 651, 0xcc4fe480, [0x3ac706a4506fa1d]) = 0
Why is the last parameter annotated by square brackets? Does it mean it represent the return value? Manual page says ptrace should return the word read for PTRACE_PEEKTEXT, but it looks strace output does not follow that, so I suspect it shows return value in the last parameter.
2. There's a section (who with bold font) between two .so but not associated with any inode. What does such section represent?
3. Gdb reads one word from that section and uses that word as an address, but actually that's an invalid address. What are the possible causes of such error?

Thanks!

Answer 1

1. Take a look at strace output for ptrace here: ptrace(PTRACE_PEEKTEXT, 651, 0xcc4fe480, [0x3ac706a4506fa1d]) = 0 Why is the last parameter annotated by square brackets? Does it mean it represent the return value?

Correct.

1. There's a section (who with bold font) between two .so but not associated with any inode. What does such section represent?

It is a region of memory that has been mmap ed with MAP_ANONYMOUNS flag (ie it doesn't correspond to any file on disk).

Since the size of that region is exactly 1MB, and since it is surrounded by private regions mapped with PROT_NONE , it is a safe bet that this region represents some thread stack, surrounded by stack guard zones.

1. Gdb reads one word from that section and uses that word as an address, but actually that's an invalid address. What are the possible causes of such error?

For some reason GDB believes that there should be code at address 0x3ac7068 , and wants to place an internal breakpoint there. GDB uses internal breakpoints to keep track of loaded shared libraries (among other things).

Output from maintenance info break should reveal what code GDB believes is residing at the "bad" address.

Answer 2

My guess is that your code is overflowing and writing over a valid address, and gdb is accessing that area of memory expecting an address but getting junk data. What is the section of code you're trying to debug? It might help us.