However, while using GDB, you might encounter the “error: GDB cannot access memory at address” error. This error can be confusing and makes it hard to keep debugging. This article is focused on identifying why this error occurs and looking at some examples of code that help us understand how to resolve this error.
Example 1:
Let us see our first code example that, upon execution, gives a “GDB cannot access memory at address” error. First, we look at the code. Then, we will see the line-by-line explanation of it.
using namespace std;
int main(void) {
int *p;
cout<<*p;
}
The program starts with the declaration of “#include <stdio.h>” preprocessor directive and using the “namespace std” which are essential to be included in the program to use the standard input and output functions. After that, the main entry point comes which is “int main(void);”. This line declares the program's starting point.
Within the main function, the “*p” pointer variable is declared. Here, the “p” variable is not initialized. Hence, it does not point to any specific memory location that is reserved for the integer. This line causes an error which we will resolve later. In the next line, we attempt to print the value of the “*p” variable using the “cout” statement.
Since the “p” variable is a pointer of type integer, the asterisk “*” is used to dereference it. This means that the value is at the memory location it points to. However, because the “p” pointer was not initialized and does not point to any specific and valid location, dereferencing the pointer will result in undefined behavior. Hence, it results in generating various kinds of errors depending on the system and compiler. Since we are using the GDB compiler to debug and run this program, the debugger will throw the following error. The error is shown in the output snippet:
As you can see in the output, the debugger cannot access the memory. This program dereferences an uninitialized pointer, the main reason for this undefined behavior. Now, let’s see how we can solve this problem. The correct code is given in the following. Have a look at it and we will explain how we fix the bug in the code:
using namespace std;
int main(void) {
int val = 5;
int *p = &val;
cout<<"The value is = "<<*p;
}
As you can see, the code is modified by including the “int val =5;” statement. This line declares an integer variable named “val” and initializes it with a value of “5”. The next line, “int *p = &val;”, declares a “*p” pointer variable and is initialized to point to the address of the “val” variable. Previously, the “*p” pointer was not pointing to any memory address which caused the “cannot access memory at address 0x0”.
To solve this issue, the “var” variable is declared, initialized, and assigned to the “*p” pointer. Now, the “*p” pointer is pointing to the address of the “val” variable as the “&” operator takes the address of “val” and assigns it to “p”. Again, the “cout” statement is used to print the value of the “*p” pointer. See the following output snippet to see the value of the “val” that is accessed by the “*p” pointer:
As you can observe, the error has been resolved and the value of “5” is initialized since the “val” variable has been printed by calling the “*p” pointer valribale.
Example 2:
Let us consider another example that explains how to cater to the “GDB cannot access memory at address” error in the C++ code program. The code is given in the following for your reference. Have a look:
int main() {
int *p = new int[15];
delete[] p;
std::cout << p[2] << std::endl;
return 0;
}
One of the most common scenarios that the developers encounter while programming with pointers is incorrect or improper memory allocation. The GDB results in the error whenever an incorrect memory allocation and deallocation occur in a C++ program.
Considering the previous code example, a “*p” pointer is initialized with a new int[15]. This statement dynamically allocates an array of 15 integers using the new operator. The “*p” pointer variable stores the memory address of the array.
In the following statement, “delete[] p;,” states that the memory has been deallocated using the delete[] command. The delete[] command deallocates the previously allocated memory of the “*p” pointer which means that the other system uses can allocate the previously allocated memory block again. When we attempt to print the value of the “*p” variable using the “cout” statement, we will get the memory access error as seen in the following output:
The things to keep in mind here is that the exact error message might differ slightly depending on your GDB version and system. But the “error: GDB cannot access memory at the location” and the given error in the previous snippet are the same. To resolve this error, we simply shift the delete[] command after the “cout” statement. See the modified code in the following:
int main() {
int *p = new int[15];
for (int i = 0; i < 15; ++i) {
p[i] = i * 2 - 5 + 8;
std::cout << "p[" << i << "] = " << p[i] << std::endl;
}
delete[] p;
return 0;
}
Here, you can see that we initialized the array with values that are calculated at run time, and we print all the values of the loop using the “for” loop. The most important thing to note here is the shifting of the delete[] statement; it is now called after getting all the values of the array which has removed the memory access error. See the final output of the code in the following:
Conclusion
In conclusion, the “error: GDB cannot access memory at address” error usually indicates memory-related issues in C++ code. This article explored some common scenarios that initiate this error to explain when and how it can be resolved. When this error occurs in the code, it is essential to carefully review it by paying a close attention to the pointer variables, memory allocations, arrays, and structures.
Moreover, features like breakpoints that are provided by GDB can help in locating the error while debugging the program. These features can help in pinpointing the exact location of memory-related errors. By addressing these issues proactively, the developers can enhance the stability and reliability of their C++ applications.
