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

Dump the raw data around the current stack pointer, and examine the contents of the return addresses.

Disassemble the function code and examine the code.

Print the memory map using the `pmap` command. 

Let's suppose you suspect that a crash occurred because the return address of a function is being overwritten by some data. What is the best way to confirm your suspicion?

Let’s suppose you suspect that a crash occurred because the return address of a function is being overwritten by some data. What is the best way to confirm your suspicion?

Function return address has been overwritten

During a debugging session, retrieving the memory pointed to by the stack pointer is giving you access violation in `frame 0`, whereas you are able to retrieve it in `frame 1`. What is the likely diagnosis?

During a debugging session, retrieving the memory pointed to by the stack pointer is giving you access violation in <code>frame 0</code>, whereas you are able to retrieve it in <code>frame 1</code>. What is the likely diagnosis?

In which direction does the stack usually grow?

In which direction does the stack usually grow?

Test your knowledge of stack corruption and overflow.

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: Stack Corruption and Overflow