Gdb monitors huge amount of memory to find out about corruption, no seg fault here
Updated:
now with valgrind --tools=memcheck --track-origins=yes --leak-check=full ./prog
it works correctly, but without it valgrind
, it still goes wrong, how does it go?
I am doing a project on Linux that stores a lot of data in memory and I need to know which data block has changed in order to find out the problem in my program.
Updated: This is a multi-threaded program and writing / reading is done by different threads created by system calls.
The code is like this
for(j=0;j<save_size;j++){
e->blkmap_mem[blk_offset+save_offset + j] = get_mfs_hash_block();
memcpy(e->blkmap_mem[blk_offset + save_offset +j]->data, (char *)buff + j * 4096, 4096);
e->blkmap_mem[save_offset+j]->data = (char *)(buff + j* 4096);
e->blkmap_mem[blk_offset+save_offset + j]->size = 4096;
e->blkmap_addr[blk_offset+save_offset + j] = 1;
And I want to know if it has changed e->blkmap_mem[blk_offset+save_offset+j]->data
elsewhere.
I know that awatch exp
in gdb
can verify that the value has changed, but here too, there is a way to keep track of all of them, I mean, they can be nearly 6,000.
Thanks to your guys.
source to share
Reverse debugging has a lot of precedent here, assuming you have some way to detect corruption as soon as it happens (the seg error will do well).
Once you find corruption in your debugging session, you place a watchpoint on the damaged variable, and then run the program backwards until the variable is written.
Here's a step by step guide:
- Compile the program with debug symbols as usual and load it into gdb.
- Run the program using
start
.- This puts a breakpoint at the very beginning of main and runs the program until it hits it.
- Now put a breakpoint somewhere where memory corruption is detected
- You don't need to do this if you encounter seg error corruption.
- type
record
to start executing the burner- This is why we called
start
before - you cannot record when there is no process.
- This is why we called
-
continue
to start the program again.- The program will run very slowly while recording
- It can tell you that the write buffer is full - if it does, tell it to wrap around.
- When your damage is detected by your breakpoint or seg error, the program will stop. Now put
watch
on any damaged variable. -
reverse-continue
to run the program backwards until the damaged variable is written. - When the vantage point hits, you discover your damage.
- Note that this is not always the first or only damage to this variable. But you can always keep working backwards until you finish your reverse execution history - and now you have something to fix.
There is a helpful tutorial here that also discusses how to manage the write buffer size in case this becomes a problem for you.
source to share