Confronting the Most Challenging “Memory Ghosts” in C/C++: Are You Still Using printf?

Code Xiaobian^{MillionFans CertifiedAccount}

By clicking follow, you not only gain a tool for finding resources but also an interesting soul ▶ ▶ ▶

Memory is a great helper for C/C++ programmers. One of the reasons we often say that C/C++ programs have higher performance is that they allow for manual memory management. However, memory issues also bring endless troubles to C/C++ programmers.

Memory-related bugs are often difficult to locate because when a program starts to behave abnormally, it is usually far from the actual point of failure. Common debugging methods often struggle to identify such issues.

Since these problems are usually caused by memory read and write operations, it would be great if we could observe when a certain memory segment is modified or read, fortunately, such technology has already been implemented.

An Example

In GDB, you can add a watchpoint to monitor a memory segment. When this memory is modified, the program will stop, allowing us to know exactly which line of code modified that memory. Isn’t this feature powerful?

Next, let’s explain with an example. Consider the following code:

#include <iostream>
#include <thread>
using namespace std;

// Thread modifies variable value
void memory_write(int* value) {
  *value = 1;
}

int main()
{
    int a = 10;
    // Get the address of local variable a
    int* c = &a;

    for (int i = 0; i < 100; i++) {
      a += i;
    }

    cout << a << endl;

    // Pass the address of variable a to the thread
    thread t(memory_write, c);
    t.join();

    return 0;
}

This code is very simple. It creates a local variable a, then gets the address of variable a and assigns it to pointer c. After that, it performs an accumulation on variable a and outputs its value, which is 4960 at this point.

Suppose you later find that the value of variable a has unexpectedly changed to 1. However, due to the complexity of the code, you do not know which part of the code modified variable a. In the above code, we use thread a to simulate this scenario. After the thread obtains the address of variable a, it modifies it to 1. Next, we will use the debugging tool gdb to locate who modified variable a.

Start Capturing the “Perpetrator”

Compile the above code, and then use gdb for debugging. Assume the source file is named a.cc, and the compiled executable is named a:

$ gdb a.out
(gdb) b a.cc:20
Breakpoint 1 at 0x400f23: file a.cc, line 20.
(gdb) r
Starting program: /bin/a
Breakpoint 1, main () at a.cc:20
20          cout << a << endl;

The above debugging command (b a.cc:20) sets a breakpoint at line 20 of the code. When the program runs to this point, it will pause. The debugging command r indicates to start running the program. You can see that it pauses at line 20, and now let’s check the address of variable a:

(gdb) p &a
$1 = (int *) 0x7fffffffe508

We can see that variable a is located at memory address 0x7fffffffe508. Now, the key point comes: how do we tell gdb to monitor whether the value at this memory address 0x7fffffffe508 has been modified? It’s simple:

(gdb) watch *(int*)0x7fffffffe508
Hardware watchpoint 2: *(int*)0x7fffffffe508

We use the watch command to have gdb monitor a memory area starting from 0x7fffffffe508 with a size of 4 bytes (assuming int occupies 4 bytes). This is the meaning of the command watch *(int*)0x7fffffffe508:

Additionally, there is something noteworthy in the gdb output:

Hardware watchpoint 2: *(int*)0x7fffffffe508

Take note, what is a Hardware watchpoint? Let’s keep that in suspense for now; we will discuss it later. Next, we run the c command in gdb, which means continue, allowing the program to keep running:

(gdb) c
Continuing.
4960

At this point, line 20 has executed and printed the value of variable a, which is 4960. Let’s continue:

[New Thread 0x7ffff6f5c700 (LWP 531823)]
[Switching to Thread 0x7ffff6f5c700 (LWP 531823)]
Hardware watchpoint 2: *(int*)0x7fffffffe508

Old value = 4960
New value = 1
memory_write (value=0x7fffffffe508) at a.cc:8
8       }
(gdb)

Haha, gdb successfully captured which line of code modified the memory at 0x7fffffffe508, and provided us with all the details. We can see that gdb printed the previous value of this memory was 4960, the modified value is 1, and it was modified at a.cc:8, which is where our thread modified variable a. Gdb successfully captured the “perpetrator”; it turns out this thread “unintentionally” modified the value of variable a.

Isn’t that amazing?

High-Quality Original Review

The hardest IT company to get into in China…

Did Elon Musk cut off a social media influencer’s $21,000 bi-weekly advertising income after she refused to have his child?

A colleague from outsourcing attended a dinner, and just as he arrived at the door of the private room, he heard the supervisor say: “We are all insiders, so from now on, any dirty or tiring work will be given to outsourcing. They are here to serve us, so don’t feel embarrassed.”

After leaving the job, a bug appeared online, and the interface was developed by himself; the n+1 compensation was reclaimed.

Heard that the internet doesn’t hire people over 35 anymore?

Programmers are starting to engage in “defensive programming” to protect their jobs…..

Did ByteDance’s recent actions directly change everyone’s habits?

A Huawei employee revealed: Most people in OD peak upon joining! Level D4, except for a 3k monthly salary increase when promoted to D5, the salary has never increased at other times.

Don’t forget to share, bookmark, and like!