Gain insights into debugging Linux process and kernel failures using GDB and crash utility. Delve into memory dump analysis, identifying issues like memory leaks, CPU spikes, and deadlocks.

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

How do we identify the owner of a mutex `m`?

How do we identify the owner of a mutex <code>m</code>?

Two threads are stuck waiting after acquiring mutex locks. What should we suspect?

Two threads are stuck waiting after acquiring mutex locks. What should we suspect?

Examine the execution residue of the suspected thread.

While examining a core dump, we suspect that an inconsistent system state was caused by some exception, but we do not see it in the stack trace of any thread. What's the best way forward?

While examining a core dump, we suspect that an inconsistent system state was caused by some exception, but we do not see it in the stack trace of any thread. What’s the best way forward?

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: Deadlocks