C/C++ Segment Fault Case Analysis and Debugging Techniques

In many of our products performance and stability problems have repeatedly resurfaced despite accumulated experience, prompting the need to systematically collect, organize, and analyze historical cases so that developers can stand on the shoulders of their predecessors.

The following sections classify typical C/C++ program core dump scenarios and describe concrete debugging methods.

2.1 Core Dump Classification and定位方法

After a crash, the most common tool is gdb , which reveals the stack trace from the core file. Based on the completeness and reproducibility of the stack, three main categories are identified:

Stack complete and stable : The stack provides clear information (e.g., division by zero, null pointer dereference, iterator invalidation). Errors can be pinpointed directly from the trace.

Stack complete but unstable : The stack varies between crashes, often indicating race conditions or nondeterministic memory corruption.

Stack corrupted : The stack itself is damaged, usually caused by severe memory overruns or misuse of low‑level resources.

2.1.1 Stack Complete and Stable

Typical errors include:

Code errors on the stack line itself (e.g., division by zero, null pointer access).

Incorrect function context (e.g., uninitialized variables, memory overflow).

Functions that appear correct but are called from higher‑level code that violates usage rules.

Reviewing library documentation and known pitfalls can often resolve these issues quickly.

2.1.2 Stack Complete but Unstable

These problems are often related to multithreading. Reducing concurrency to a single thread can help confirm the root cause. Look for data races, missing locks, or excessive logging that masks the bug.

2.1.3 Stack Corrupted

When the stack is overwritten, the cause is usually a memory overrun. Common sources include:

Compilation vs. runtime environment mismatches.

Memory out‑of‑bounds writes.

Binary search rollback of recent code changes is an effective way to isolate the offending segment.

2.2 Case Analysis

Based on collected incidents, we grouped core dump reasons into five categories and present three representative ones here.

2.2.1 Improper Exception Handling

Neglecting return‑value checks or failing to catch exceptions can leave the program in an inconsistent state. Example code (simplified):

if (func() != SUCCESS) {
    log_error();
    cleanup();
    return;
}

Additionally, using stale data after a failed operation (e.g., sqas_res->knowledge retaining a previous query's value) can cause crashes.

2.2.2 Multithreading / Multiprocessing Issues

Common pitfalls:

Calling non‑reentrant functions (e.g., strtok , gethostbyname ) without thread‑safe alternatives.

Insufficient critical‑section protection, leading to double‑free or use‑after‑free errors. See code snippet 2‑2 for an unprotected list destroy.

2.2.3 Third‑Party Library Misuse

Changing protobuf field types without respecting compatibility rules, or misusing library APIs (e.g., assuming a function returns a null pointer on error when it returns an error code) can introduce crashes.

2.2.4 Poor Program Design

Typical design‑related causes include memory leaks leading to OOM, unsigned‑signed conversion errors, incorrect handling of pthread_t on 64‑bit systems, infinite loops that exhaust resources, and improper initialization/cleanup order.

2.2.5 System Library Misuse

Errors such as providing an invalid comparator to sort , using printf with unchecked format strings, unsafe string functions ( strcpy , strncpy ), iterator invalidation during container modification, and exceeding select ’s file‑descriptor limit can all cause core dumps.

By understanding these patterns and applying the suggested debugging steps, developers can significantly reduce the recurrence of segmentation faults in C/C++ projects.