Runing Backtrace, It shows an error. What does the hexadecimal number represent at the end of a this line:
======= Backtrace: =========
/lib64/libc.so.6(__cxa_finalize+0x8e)[0x323aa337de]
The address at the end (0x323aa337de) is value of the program counter (the RIP register on x86-64). According to your debug symbols, this address is equal to __cxa_finalize+0x8e, i.e. 0x8e bytes past the start of the __cxa_finalize function within the C runtime shared library (/lib64/libc.so.6).
In Library, lib64/libc.so.6, function __cxa_finalize is currently being executed.
You are at 142 bytes (0x8E) in from the start of the function.
This is at memory address 0x323aa337de.
This is either where the program crashed, or the instruction you are currently looking at in the debugger (depending on context).
Related
I want to print 1 words from the top of stack in the form of hexadecimal. To do so, I typed the following:
(gdb) x/1xw $esp
but GDB keeps popping up:
0xffffffffffffe030: Cannot access memory at address 0xffffffffffffe030
The program I'm trying to debug has already pushed a value onto stack so just in case if you're wondering that I might be trying to access kernel variables at the very beginning of program, it's not so.
Any idea?
0xffffffffffffe030 is a 64-bit constant, so you are running in x64-bit mode. But $esp is a 32-bit register (which GDB sign-extends to 64 bits in this context). The 64-bit stack pointer is called $rsp. Try this instead:
(gdb) x/1xw $rsp
I cannot set 4 byte read / write access hardware breakpoint using windbg.
0:000> dd 02e80dcf
02e80dcf 13121110 17161514 1a191800 1e1d1c1b
02e80ddf 011c171f c7be7df1 00000066 4e454900
Actually I have to check when the value 0x13121110 (at address 0x02e80dcf)is getting changed/overwritten by the program.
So When I'm trying to set a 4 byte write access hardware breakpoint # 0x02e80dcf, I'm getting Data breakpoint must be aligned Error.
0:000> ba w 4 02e80dcf
Data breakpoint must be aligned
^ Syntax error in 'ba w 4 02e80dcf'
0:000> ba r 4 02e80dcf
Data breakpoint must be aligned
^ Syntax error in 'ba r 4 02e80dcf'
0:000> ba w 1 02e80dcf
breakpoint 0 redefined
I'm able to set 1 byte write access breakpoint at the address, But it not getting triggered when the pointer # address 0x02e80dcf is getting overwritten.
And also if anyone could suggest any other way to detect the address overwritten thing would be really helpful.
Note : The problem I'm facing for a particular program. I'm able to set 4 byte hardware break point in the same debugging environment.
As a side note, this particular behavior is from the CPU architecture itself (not from the system or the debugger).
x86 and x86-64 (IA32 and IA32-e in Intel lingo) architecture use Drx (Debug Registers) to handle hardware breakpoints.
Dr7 LENn field will set the length of a breakpoint and Dr0 to Dr3 will hold the breakpoint addresses.
from Intel Manual 3B - Chapter 18.2.5. "Breakpoint Field Recognition":
The LENn fields permit specification of a 1-, 2-, 4-, or 8-byte range,
beginning at the linear address specified in the corresponding debug
register (DRn).
In the same chapter it is explicitly stated:
Two-byte ranges must be aligned on word boundaries; 4-byte ranges must
be aligned on doubleword boundaries.
If you cover the desired address with a data breakpoint with a big enough length, then it will trap (breakpoint will be hit):
A data breakpoint for reading or writing data is triggered if any of
the bytes participating in an access is within the range defined by a
breakpoint address register and its LENn field.
The manual then goes on giving a tip to trap on unaligned address and gives an example table:
A data breakpoint for an unaligned operand can be constructed using
two breakpoints, where each breakpoint is byte-aligned and the two
breakpoints together cover the operand.
Addresses must be aligned on a 4-byte boundary (or larger for 64-bit systems).
Any hex address ending in 0xf is not aligned to a 4-byte boundary.
There may be a restriction by WinDbg that data breakpoints are aligned to 4 or 8 byte boundaries. You many need to use conditional break so that only the one byte is checked.
I was debugging a C++ code using gdb. The program stopped due to a segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
So I was trying to print out the value of variables to identify where the error is coming from. I have an array called 'ring' of type 'Link **', where Link is a class I defined. Each element in the array points to a 'Link *' variable. Here is the output when I print the first three elements of the 'ring' array.
(gdb) print ring[0]
$13 = (Link *) 0x8125290
(gdb) print ring[1]
$14 = (Link *) 0xb7e80b86 <exp+6>
(gdb) print ring[2]
$15 = (Link *) 0x8132e20
Why am I getting '' after the memory address when printing 'ring[1]'? What does it mean?
EDIT: Im using gdb 7.8 on Arch Linux (3.16.4-1-ARCH)
It means the pointer value is equal to the address of the exp symbol plus 6. It's just the debugger trying to be helpful—whenever it decodes any pointer value, it tries to see if the pointer happens to lie near any known symbols in the object code, and it prints out that information if so.
You might expect to see such notation when examining the disassembly of a function's code, e.g. in branch targets, but as a data pointer, that's very unusual (function pointers would tend to point directly at function symbols, not offset into them).
You almost certainly have some kind of memory corruption bug that just happens to produce that value as a side effect.
We have a posix mutli-threaded C++ program running on Linux 2.6.32, which core-dumps in one of the threads. Analysing the core file with gdb-7.2 corss-compiled, we see that the faulting instruction is here
0x11491178 <+208>: lwz r0,8(r9)
and registers in the frame show:
(gdb) info reg
r0 0x0 0
….
r9 0xdeaddead 3735936685
Which makes sense as r9 has an invalid address value(in fact heap scrub pattern we write) in the context of the process/thread.
The confusing bit is that r9 is loaded from like this
0x1149116c <+196>: lwz r9,0(r4)
and r4 contains the value of (first and only) function parameter "data". GDB tells me the following information about data:
(gdb) p data
$6 = (TextProcessorIF *) 0x4b3fe858
(gdb) p *data
$7 = {_vptr.TextProcessorIF = 0x128b5390}
(gdb) info symbol 0x128b5390
vtable for TextProcessorT<unsigned short> + 8 in section .rodata
Which is all correct in this context. So r9 should have had a value of 0x128b5390 instead of the pattern "0xdeaddead" which is written when the memory is free'd and given back to the heap.
So, why the register r9 contains the scrubbed value when the memory contains a legal object. My theory is that the core contains snapshot of the memory just as the process died which is much further down the line when the actual crash happened. After the SIGSEGV has been raised, this location of the heap memory can still be used by other threads as they are logging data till the time process dies. So, it is possible that the memory pointed to by data maybe have been allocated again and being used/been used at the time memory snapshot has been taken and preserved in core.
My question is:
A) Is my theory correct?
B) Am I right in presuming that the heap memory snapshot is not taken at the time crash (signal being raised) but at in the final moments of the process?
C) Address/location that caused a SIGSEGV can still be used (by other threads)?
Thanks!
Do you use signal handler(s) for SIGSEGV? Are they asynchronous and re-entrant?
See How to write a signal handler to catch SIGSEGV?
I met a SEGV_MAPERR crash in my program.
pid: 934, tid: 934, name: Binder_1 >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000006
backtrace:
#00 pc 00000006 <unknown>
#01 pc 00006925 /system/lib/libcutils.so (set_sched_policy+136)
#02 pc ffffffff <unknown>
I can understand the fault address is 0x00000000 or 0x00000004 or something others. For example, invalid class virtual base pointer, or invalid/wild function pointer.
But I can not understand the 0x00000006 as a fault address. Was the stack modifed illegally? But nearby the wrong code, neither the return statement, nor jump instrument were found.
Is there any other potential reason? Thank you very much!
I don't see why you find it strange. This would be is a typical outcome of attempting to access memory location at offset 6 through a null pointer. For example, if you have char *string and access string[6] when string happens to be a null pointer, you will typically get segfault at address 6. Access string[7] and get a segfault at address 7 (Wow! This one is not even even!!!) That way you can access absolutely arbitrary address and get a segfault on it.
(The pedantic stuff: ... assuming that null pointer is represented by zero address and that char matches the machine byte)
If the segfault was caused by control transfer to address 6, then there could be many different reasons for it. For example, a call was performed through an invalid function pointer that somehow acquired value 6 (an uninitialized pointer, a pointer damaged by a buffer overrun nearby). Alternatively, stack location that stores the return address from a function could have been damaged by a buffer overrun and acquired value 6, which caused control transfer to address 6 at function return. And so on and so forth.
You yourself mention "invalid/wild function pointer" as a possible reason. But why do you find it surprising then that the control got transferred to address 6? An invalid pointer can acquire an arbitrary value, not necessarily aligned on 4-byte or 8-byte boundary.