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

    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


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

1 answer

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.
  • 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.



All Articles