Thread: Help/ideas on how to catch a difficult but that write at random memory locations

If the code is compiled without optimising and with the compiler emitting debug information, any debugger will be able to identify what code writes to the affected memory.

The catch is that, unless your code is compiled that way, it will need to be recompiled. And the changes will affect layout of memory in your program, so may cause the offending code to write to a different location in memory.

You could also add output statements (e.g. write the affected values to stdout or stderr in selected places) and use those output values to localise the code which causes the problem. The catch is that, potentially, even an additional I/O statement can potentially change memory layout of the program (although that is less likely than recompiling with different settings, it is possible).

If you don't want to do the above (or tried them and find the symptom changed) I suggest eliminating sections of your program systematically. If the symptom vanishes on removing some section of code, then that's not definitive, but does give hints. The possibilities are

1) there is a flaw in the code you just removed.
2) there is a flaw in some code you previously removed, which interacts somehow with the code you just removed.
3) there is a flaw in some code you haven't removed yet, which interacts with some code you have just removed.
4) combinations of the above

There could still be a flaw in code you haven't removed, but a systematic approach keeping the above points in mind can narrow down the odds.

Not withstanding your claim the code is complex, I suggest using code inspection - 25000 may seem like a lot to you, but it's really not that much, unless the code is really badly written. Look for code that uses computed pointers (e.g. a pointer used to select something based on user input), that uses computed array indices (look for off-by-one errors in loops, falling off the end of an array, indices computed from data in files, etc). Also look for code that is excessively "clever" in playing with pointers - usually programmers who are too clever playing with pointers get it wrong.

Welcome to the land of debugging. It is VERY difficult to write code that is bug free. It is often VERY VERY difficult to find a bug once it exists.

Which OS / Compiler are you using? This helps us identify suitable tools.

For example, if you set up a large block of memory at initialisation time, which is supposed to be read-only, but later corrupted, then one thing to look into is how your OS could protect areas of memory by marking them read-only.

Then at least the program would crash on the errant write instruction (giving you useful information), rather than having to wait until something stumbles into the minefield.