1

I debugged a program with segv at a command like *p = a;

In GDB, it is fine to do

Breakpoint 2, Foo (size=4) at bar.cpp:144
144       meta->requested_size = size;
(gdb) p meta->requested_size = size
$9 = 4
(gdb) p &meta->requested_size
$10 = (size_t *) 0x7021fffffff8
(gdb) p *0x7021fffffff8 = size
$11 = 4

with crash, while n causes segv.

(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00005555555a3dcb in Foo (size=4) at bar.cpp:144
144       meta->requested_size = size;

(gdb) p $_siginfo._sifields._sigfault.si_addr
$12 = (void *) 0x7021fffffff8

By How can I check whether a memory address is writable or not at runtime?, I found this address is not writable. Is this gdb's result expected?

Joe C
  • 2,757
  • 2
  • 26
  • 46
  • Please, before doing `n`, dump the memory map of your program with the command `info proc mappings` and attach the result to your question. Also, when you do please adjust any value/address if it changes! This is important, we need the code you show to be consistent (do not mix stuff from two different executions of the program). – Marco Bonelli Mar 01 '21 at 10:21
  • Related: [How does ptrace POKETEXT works when modifying program text?](https://stackoverflow.com/questions/49442087/how-does-ptrace-poketext-works-when-modifying-program-text). On Linux, GDB uses [ptrace](https://man7.org/linux/man-pages/man2/ptrace.2.html), which has a long, undocumented history of allowing a debugger to modify non-writable sections of a process image. – Mark Plotnick Mar 01 '21 at 15:23

1 Answers1

0

gdb is a debugger tool. It lets you do virtually anything without restraints because you are trying to poke and prod at things to see what happens. Safety restraints would only get in the way.

orlp
  • 112,504
  • 36
  • 218
  • 315