Virtual Memory and Memory Dumps

The fundamentals

Our primary goal is to help you rapidly acquire proficiency in core dump analysis. So first, we’ll review the fundamentals necessary for core dump analysis. Also, this course is mostly about user process core dump analysis with an accelerated transition to kernel core dump analysis.

Those of us who come from Windows or Mac OS backgrounds will find the fundamentals almost the same. The Linux virtual memory range is divided into a kernel space part, a user-space part, and an inaccessible part for catching NULL pointers for every process. In this course, we’re running Ubuntu on x86 machines, where this inaccessible part is from 0x0000 to 0xFFFF (as can be seen from the /proc/sys/vm/mmap_min_addr value).

Note: We follow the long tradition of using red for the kernel and blue for the user part. A key thing to remember is that there is a difference between space and mode.

Try it out

Use the cat command to display the contents of the /proc/sys/vm/mmap_min_addr file in the terminal below. This will display the minimum valid address for the user memory. Any address that is lesser than this is inaccessible.

The difference between mode and space

A mode is the execution privilege attribute; for example, code running in kernel space has a higher execution privilege than code running in user space. The kernel code can access user space and access data there. We say that such code is running in kernel mode. On the contrary, the application code from user space is running in user mode, and because of its lower privilege, it can’t access kernel space. This division prevents accidental kernel modifications. Otherwise, we could easily crash our system.

In the illustrations, we have put the addresses on the right. This uniform memory space is called virtual process space because it is an abstraction that allows us to analyze core dumps without thinking about how it is all organized in physical memory.

Note: When we look at process dumps, we are concerned with virtual space only.

When an app is loaded, all its referenced dynamic libraries are mapped to virtual memory space.
Different sections of the same file (like code and data) may be mapped into another memory portion. In contrast, modules in Windows are organized sequentially in virtual memory space.

A process is then set up for running, and a process ID is assigned to it. If we run another such app, it will have a different virtual memory space.

Memory dumps

A memory dump is technically the process of taking the contents of the RAM and writing them into a readable file, also referred to as a memory dump. We'll categorize these memory dumps into two categories: process memory dump and kernel memory dump.

Process memory dump

When we save a process core memory dump, the user-space portion of the process space is saved without any kernel space stuff. However, we never see such large core dumps unless we have memory leaks. This is because process space has gaps that do not contain any code or data.

Note: These unallocated parts are not saved in a core dump.

However, if some parts were paged out and reside in a page file, they are usually brought back before saving a core dump.

Let’s take a look at this visualized below for better understanding.

Kernel memory dump

In case of a kernel panic, a kernel memory dump is saved if the appropriate mechanism is configured
(mostly by default for recent distributions, such as Ubuntu).

Note: Virtual memories of running processes are not saved, however. For that, we need various physical memory acquisition methods and tools that are outside the scope of this course.

Fiber bundle memory dump

The lack of complete memory dumps may be circumvented by dumping individual processes and then using them together with the kernel memory dump. We call the resulting dump-type fiber bundle. We can see the concept of the fiber bundle being visualized below.