The difference between gdb addresses and "real" addresses?

Question

If I run a C / C ++ program in gdb (after compiling with the -g flag) and I look at the addresses of certain variables, arguments ... etc., and then run it outside of gdb (using ./ ) will Are these addresses the same as the ones I saw in gdb? If they are different, are they usually similar or will they be very different?

I ask about this because I have a buffer overflow program that works fine in gdb (with and without breakpoints), however, when I try to run it outside of gdb, it does not work.

Answer 1

I look at the addresses of certain variables, arguments ... etc., and then run it outside of gdb (using. /), Will these addresses be the same as the ones I saw in gdb

It depends.

• Global variables defined in the main executable will remain at the same address (if the executable is not built with -fpie and is associated with the -pie flags.
• Global variables defined in other shared libraries can have completely different addresses due to ASLR .
• Local variables and parameters can be moved by several K-bytes due to ASLR.
• Variables separated by heaps can also move abruptly due to ASLR or if your program is multithreaded.

Note that GDB on Linux disables ASLR by default to facilitate debugging. You can re-enable ASLR in GDB with set disable-randomization off . This may allow you to reproduce the problem in GDB.

I have a buffer overflow

Also note that tools like Valgrind and Sanitizer Address are often much more efficient at finding buffer overflows than when working in GDB. The Sanitizer address, in particular, is remarkable in that it detects buffer overflows in globals and on the stack (Valgrind does not).

Answer 2

You should never assume that a certain code or vars will be located in a fixed place.

It was in the past in most OSs, but it is a security hole. Malicious software uses this to raise programs. The OS will strive to scramble addresses for increased security.

Answer 3

Compiling with the -g flag increases the size of the code when pasted into executable additional information.

As for your buffer problem, this will help to post a piece of code in which everything goes wrong.