1. Overview

In embedded Linux product development, debugging, and delivery, crashes like segmentation faults and stack overflows are common. Serial logs alone often cannot pinpoint the exact failure scenario.

Core Dump is a crucial debugging mechanism provided by the Linux operating system: when a process terminates abnormally, the system saves the key runtime state of the process at the moment of the crash (including memory image, registers, call stack, etc.) into a file. Developers can use debugging tools like gdb to perform offline analysis on this file, enabling them to quickly identify the root cause of the issue.

This article uses the OK3568 platform (Linux Kernel 5.10 + Buildroot) as an example to provide a detailed explanation of how to enable Core Dump functionality and offers practical debugging methods, applicable to scenarios such as application development, system integration, and customer issue analysis.

2. Core Dump Concepts

Core Dump may be triggered when an application exits abnormally due to the following situations:

• Accessing illegal memory (Segmentation Fault)
• Null pointer or wild pointer access
• Stack overflow
• Illegal Instruction
• Program actively calling abort()

The generated core file is essentially a snapshot of the process’s address space at the moment of the crash, mainly including:

• The virtual memory content of the process (code segment, data segment, heap, stack)
• CPU register states
• Thread information
• Signal information (the type of signal that caused the crash)

With the core file, issues can be reproduced without the target board, significantly improving the efficiency of problem analysis.

3. OK3568 Buildroot System Default Operation Description

In the default Buildroot system for OK3568 (Linux kernel 5.10), core dump is disabled.

Core Dump default function is disabled.

When an application crashes, no core file is generated automatically.

To enable in-depth debugging or scenario reproduction, please manually enable this function.

4. Steps to Enable Core Dump

On the 3568 Linux 5.10 board, core dump is disabled by default.

To enable it on the board:

4.1 Create a core dump directory

It is recommended to save the core file under a persistent partition that the user can read and write, such as /userdata

mkdir -p /userdata/core

4.2 Set directory permissions

Allow any process to write to it during debugging:

chmod 777 /userdata/core

Note: For production systems, restrict permissions according to security policy. 777 is not recommended for long-term use.

4.3 Set core file directory

Configure the kernel to save cores with a descriptive name in the directory:

echo "/userdata/core/core.%e.%p" > /proc/sys/kernel/core_pattern

Parameter description:

%e：executable name

%p：process PID

Example generated file:

core.myapp.1234

4.4 Allow core dump generation

Lift the core dump size limit for the current shell:

ulimit -c unlimited

Note: This setting is session‑specific. To apply permanently, add the command to your startup script.

4.5 Verify if core dump is enabled

After enabling, use the ulimit -c command to check whether the dump feature is active.

If the output is 0, it indicates that the dump function is disabled.

If the output is unlimited, it indicates that the dump function is enabled.

5. Verify core dump generation

After completing the setup above, run your target application.

When the program crashes (e.g., due to a segmentation fault), a core file will be generated in the configured directory (/userdata/core/) with the following naming pattern:

core.<program_name>.<process_pid>

6. Debug with GDB

6.1 Basic debug command

Use a matching GDB (typically a cross‑debugger) on your host or target board:

gdb <program_path> <core_file_path>

Example:

gdb /userdata/myapp /userdata/core/core.myapp.1234

6.2 View the crash call stack

After entering GDB, input the following command:

bt

This command will print out the function call stack of the program at the time of the crash, which is the key basis for locating the problem.

6.3 Additional useful debug commands

List current threads:

info threads

Switch to the specified thread:

thread <id>

View variable values:

print <variable name>

View the current function source code:

list

7. Recommendations & Considerations

1. It is recommended to turn on -g when compiling with debug symbols, otherwise the call stack information is limited.

2. Note that the storage space may occupy a large amount of Core files. It is recommended to clean them regularly or limit the number of files generated.

3. Carefully open Core Dump in the production environment, which may contain sensitive information, and the formal product should decide whether to enable it according to the requirements.

4. Core Dump + log (syslog/application log) with the best log effect can restore the problem scenario more completely.

8. Summary

Enabling core dumps on the OK3568 Buildroot system preserves complete crash‑scene information when an application fails, significantly improving debugging and issue‑analysis efficiency. This mechanism is particularly useful for:

• Reproducing field‑reported issues
• Debugging sporadic crashes that cannot be reproduced in‑lab
• Analyzing multi‑threaded or complex‑logic failures

It is recommended to turn it on by default in the R & D and test stages, and make a choice in the mass production stage according to the safety and resource strategy.

---