Difference between gdb addresses and "real" addresses?
c, c++, gdb, hex, memory-address
Solution
I examine the addresses of certain variables, arguments...etc, and then I 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 stay at the same address (unless the executable is built with `-fpie` and linked with `-pie` flags.
- Global variables defined in other shared libraries may have drastically different addresses due to ASLR.
- Local variables and parameters may move around by several K-bytes due to ASLR.
- Heap-allocated variables may also drastically move due to ASLR, or if your program is multi-threaded.
Note that GDB on Linux by default disables ASLR, to make debugging easier. You can re-enable ASLR under GDB with `set disable-randomization off`. That may allow you to reproduce the problem under GDB.
I have a buffer overflow
Also note, that tools like Valgrind and Address Sanitizer are often significantly more effective for finding buffer overflows than running under GDB. Address Sanitizer in particular is great in that it finds buffer overflows in globals and on stack (Valgrind doesn't).
Problem
If I run a C/C++ program in gdb (after compiling with the -g flag) and I examine the addresses of certain variables, arguments...etc, and then I run it outside of gdb (using `./`) will these addresses be the same as the ones I saw in gdb? If they're different are they usually similar or will they be drastically different? I ask this because I have a buffer overflow program that works perfectly in gdb (with and without breakpoints), however when I try to run it outside of gdb it doesn't work.