FAQs
Let’s go through some of the frequently asked questions related to the material we covered in the course.
We'll cover the following...
- Why do backtraces of some threads start from main() throughout the course?
- Is it possible to use scripts in GDB?
- Is I/O or PCI-mapped memory included in process core dumps?
- Is there a way to know how much space each function takes on a stack?
- In case of multiple threads, will GDB show the thread that got the signal?
- Sometimes, we get truncated core dumps. When does this happen?
- What happens if process memory is relocated?
- Can I search for a pattern in the dump?
- Can I dump entire memory contents from a core dump? For example, I want to examine the entire contents of the memory in one command.
- Is this crash tool procedure to analyze Linux kernel core dumps also working for ESXi?
- Is there an !analyze equivalent command in GDB?
- If a thread is in kernel context, do we get to know any info on what kernel function it was executing?
- Sometimes, GDB says that it optimized away some local variables. Does it mean it doesn’t use a stack for those variables (and uses registers)?
- Can I search for an address?
- I got this output when I tried to load the lesson “Examine Normal Kernel Dumps:”
Why do backtraces of some threads start from main() throughout the course?
If you are accustomed to the WinDbg debugger, then this is a completely justified question. The simple answer to the question is that of course, they do not start there, but by default, a stack trace is shown starting from the main function in GDB. We can change this behavior by using the set backtrace past-main command.
Is it possible to use scripts in GDB?
Yes, for example, in the past we wrote the following script to emulate the WinDbg dpp command in a file UserCommands.txt:
define dpp
set $i = 0
set $p = $arg0
while $i < $arg1
printf "%p: ", $p
x/ga *(long *)$p
set $i = $i + 1
set $p = $p + 8
end
end
We load the file in GDB ...
Access this course and 1400+ top-rated courses and projects.