I am trying an example in the documentation: "x/4wx 0x54320". I expect to see 16 hex characters. Instead I get an error: "Cannot access memory at address 0x54320".
According to documentation: "address is the address where you want GDB to begin displaying memory: it is always interpreted as an integer address of a byte of memory.".
Is GDB taking "0x54320" as the location to start looking, or the address (pointer) to the location to start looking?
Anyway, all I want is to see the bytes stored starting at "0x54320". How do I accomplish this, please?
x/4wx 0x54320 is incorrect. You probably mean x/4xw 0x54320: display 4 words as hex beginning at address 0x54320. If that address is a pointer, you'll see the value of the pointer, i.e., the address it holds.
0x54320 looks suspicious to me. It's a rare address that just happens to count down in hex. But, maybe you're just lucky.
Related
I have question about line #2 and #9 of this code.
I have ran this code on codeblocks and it turns out that trip(&y) runs and make y=21 at the end of line 9. This is not what I expected.
I thought &y would return the address (like hexadecimal number) and pass it to trip. Then trip will triple the weird (hexadecimal) number of the address and perhaps change the address of int y, or produce error.
Which part of my logic has fault?
My logics are:
&y returns the address of the variable (hexadecimal).
trip (int* x) takes in the number (address in this case) and triples it.
Therefore, nothing has been done to the actual value of y, which is 7.
Edit: The answer is 105.
You are right about the address of y that is given to the function trip(int*).
Your mistake is that the function trip(int*) dereferences the address to access the value it points to.
Assume y has the value 7 and is stored at address 0x0014 (simplified for your convenience).
The function trip(int*) gets the address 0x0014 and uses it to get to the value 7 of y.
Now it triples this value and stores the result where the address is pointing to. Thus overwriting the value 7 of y with the new value of 21.
This dereferencing of the address is done by the star (*) right in front of the x in the body of the function trip(int*).
To clarify. Addresses aren't necessarily a hexadecimal value. Hexadecimal is just a way to display a number. Addresses are just the number to a certain place in memory. In this case 0x0014 is the same as 20 in decimal. Meaning y is stored at address 20 (as decimal).
Please keep in mind that pointers are rarely the right way to do something. Like in this case with the function quin(int&). The problem that is solved with a pointer in trip(int*), is solved much cleaner in quin(int&). References are cleaner and safer.
The function trip(int*) does not check for the case that the address given is invalid (the address given is NULL/nullptr). quin(int&) doesn't even have to check for this since references cannot be NULL in C++.
If you have to use pointers, consider using smart pointers like std::unique_ptr<T> and std::shared_ptr<T>.
What is the value of a memory address that is less than 12 hex digits on a 64-bit computer?
For instance, when I run gdb on a simple assembly program and run (gdb) info frame I get:
Stack level 0, frame at 0x7fffffffd970:
rip = 0x40052f in main (file.s:11); saved rip = 0x7ffff7a2d830
source language asm.
Arglist at 0x7fffffffd960, args:
Locals at 0x7fffffffd960, Previous frame's sp is 0x7fffffffd970
Saved registers:
rbp at 0x7fffffffd960, rip at 0x7fffffffd968
The first part of the second line rip = 0x40052f in main (file.s:11) I believe states the value of the instruction pointer when I called info frame. But why is the memory address it holds not 12 hex digits?
Also, if I type (gdb) x 0x7fffffffd968 (which I expect to be 0x7ffff7a2d830) I get:
0x7fffffffd968: 0xf7a2d830
Does this mean that any memory address with less than 12 hex digits contains an implicit 7ff...?
No. On x86 or x86_64, a memory address is simply a number, but is commonly displayed using hexadecimal. And like most number notation systems, a shorter number just means a much smaller value, or if you like, there are implicit zeros before it.
So just like the decimal string "12" is much smaller than "12654321", the address 0x40052f is much smaller than the address 0x7ffff7a2d830. The two addresses are almost certainly in different virtual memory maps. (On Linux, you can view virtual memory maps by cat /proc/{pid}/maps.)
When you used the gdb x command, you didn't see the value you expected because gdb took a guess at what kind of data your address points at. The first time you use x in a gdb session, it defaults to showing 4 bytes (32 bits) per element, as though the address points at an array of uint32_t. Since addresses on x86_64 are 8 bytes (64 bits), you need x/g to tell gdb the element size is 8 bytes.
I'm trying to find the source of an APPCRASH and I've learned that you can find the start memory address of the .exe file your running, and add the memory address of the 'Exception offset' onto that and find that address in assembly, to see the line of code causing the problem. I'm not sure how to 'add' memory addresses. The start module of the .exe is at address 00190000-0021D000 - that doesn't look like the memory addresses I know! (It's much longer!)
How do I add 0002207b onto that address to see where the access violation is? (I tried converting both to decimal, adding the decimals, and converting back again, but the result was empty).
string * sptemp = (string *) 0x000353E0;
What does this code exactly want to say ?
I know that in the left side we define a string pointer but I couldn't understand the right part.
It means take a numeric value, convert it to a pointer with that value as the address it points to, and then use that value to initialise the variable sptemp.
If the memory at that address contains a valid string object, then you can use the pointer to access it. If not, trying to do so will give undefined behaviour.
string * sptemp = (string *) 0x000353E0;
What does this code exactly want to say ?
It says, treat the data located at address 0x000353E0 as though it holds a string and assign the address to the variable sptemp. The data can be accessed through the pointer variable sptemp after that.
These comments are mostly right, but not completely. We don't actually know that string is std::string here. It could be that string is a bit of memory-mapped hardware whose address on the OP's embedded SBC is defined by the hardware 0x000353E0. In that case, this is completely sensible, and what people do all the time. The pointer "string *sptemp" is set to point to the hardware interface.
But it's probably nonsense.
While debugging a Linux app, I found a pointer with the suspicious value 0x7c7c7c7c. Does that particular value indicate anything?
(I ask because I know from my MSVC days that in a debug build, values like 0xcdcdcdcd or 0xdddddddd would be stored into heap blocks that were uninitialized, freed, or otherwise invalid. Some people use magic values like 0xdeadbeef or 0xcafebabe in uninitialized memory. I'm guessing something in libc or elsewhere uses 0x7c7c7c7c as a magic value, but I can't find it documented.)
I don't recognize that magic number, and neither does Wikipedia. I would guess that some code in your program (or in a library you're using) is using memset() and hitting your pointer. Have you grepped your code base case-insensitively for the string "0x7c"?
0x7C is an ASCII pipe "|" character. You could search for writes of that character as well 124 and 0x7C as Adam suggested.
0x7c7c = 01111100 01111100 in binary. That could be one of those "most difficult to read" bit patterns that format utilities fill unused space on hard drives with.
Maybe the MALLOC_PERTURB_ environment variable is set? If set, it influences how malloc() initializes the allocated memory.