Accelerated Linux Core Dump Analysis Second Edition.png

support.tar.gz

Challenge

Exercise

Linux_core_dump_analysis_notebook

Live Linux_core_dump_analysis_notebook

Final_Linux_core_dump_analysis_notebook-copy

It’s essential to examine core dumps to diagnose any non-trivial hangs or crashes due to a user process or the kernel faults. Most people have no training in dealing with core dumps, so the causes of most crashes remain undiagnosed.

This course starts with debugging core dumps. You will learn how to debug the Linux process and kernel failures (using the GDB debugger and the crash utility), browse core memory dumps, identify corruption, memory leaks, CPU spikes, halted threads, deadlocks and wait chains, among other things.

Instead of taking a theoretical route, you will focus on hands-on lessons on a variety of memory analysis patterns found in 64-bit core memory dumps from the x64 architecture. You will follow the novel pattern-oriented diagnostic analysis approach that considerably helps with the analysis. Moreover, the course will provide you with problematic applications and the associated core dumps, along with brief descriptions of relevant patterns and some frequently asked questions.

Accelerated Linux Core Dump Analysis

You open a process core dump, type `bt`, and see an exception in the stack trace. What would be the next step to verify?

You open a process core dump, type <code>bt</code>, and see an exception in the stack trace. What would be the next step to verify?

Disassemble the function that contains the instruction using `disass <instruction-address>`.

Fetch the instruction using `x/i <instruction-address>`.

Examine stack contents for return addresses using `x/xg $rsp`.

Examine symbolic information in the stack trace.

**(Select all that apply.)** You’ve loaded a core dump and have found the address of the instruction that caused the crash. Which options can be the next step to identify any possible `NULL` pointer dereferencing? 



(Select all that apply.) You’ve loaded a core dump and have found the address of the instruction that caused the crash. Which options can be the next step to identify any possible <code>NULL</code> pointer dereferencing?

`gdb -c <dump-file> -se <executable-file>`

`gdb -c <dump-file> -e <executable-file> -s <symbol-file>`

`gdb -c <dump-file> -e <executable-file>` followed by `symbol-file <symbol-file>` from within the `gdb`.

`gdb -c <dump-file> -s <symbol-file>` followed by `file <executable-file>` from within the `gdb`.

**(Select all that apply.)** You’ve been given a core dump, the executable file that generated it, and the symbol file. What’s the correct sequence of `gdb` commands to load the core dump, along with the executable file and the symbolic information? 



(Select all that apply.) You’ve been given a core dump, the executable file that generated it, and the symbol file. What’s the correct sequence of <code>gdb</code> commands to load the core dump, along with the executable file and the symbolic information?

 Can’t access memory at address `0x11a7`.

What is the expected outcome of the following sequence of GDB commands?

```SHELL
info r $rax
# the output suggest $rax has 0x11a7 value.
x $rax
```

What is the expected outcome of the following sequence of GDB commands?
<pre><code class="language-SHELL">info r $rax
# the output suggest $rax has 0x11a7 value.
x $rax
</code></pre>

Test your knowledge of NULL pointer patterns and external debugging information.

Getting Started

Fundamentals of Core Dump Analysis

Using GDB With Multi-Threaded Applications

Null Pointer Patterns and External Debugging Information

Spiking Threads

Heap Corruption

Stack Corruption and Overflow

Active Threads

Runtime Exceptions and Execution Residues

Heap Errors

Deadlocks

Post-processing

Kernel Dump Analysis with Crash

Wrapping Up

Appendix

Quiz: NULL Pointer Patterns and External Debugging Information