Re: Memory protection between compilation units?

On 12/06/2025 14:31, Mateusz Viste wrote:

On Wed, 11 Jun 2025 17:14 David Brown wrote:
 

For debugging problems like this with gdb, you can put a data
breakpoint on the pointer that is your known symptom.  Set it to stop
when something writes 0 to it - then you can see where you are in
code when that happens.  Of course, that will be a real pain if it
only happens once a week.

 The idea is good, but as you observed it is hard to apply in a
production situation when the issue happens like three times a month.
 In fact, a breakpoint would be even overkill - I'd be perfectly happy
for the program crashing when said variable changes. Like a
runtime-setup assertion that constantly checks the state of the
variable. Sadly, I'm not aware of such mechanism either. :)
 

Run-time assertions or other specific run-time checks will be triggered when they see the given condition.  For example, if you had compiled with "gcc -fsanitize=null", then you'd get a run-time error and "crash" when the null pointer was dereferenced.
But that only tells you when you look at the corrupted data - it tells you nothing about when the data was corrupted.
A data breakpoint is triggered when the data item is written (or read, depending on the settings).  I have only used these on embedded systems, and don't know about their support in x86 hardware (assuming that is your target).  But the point is that the breakpoint would be hit in the buggy code with the buffer overrun, rather than in the correct code that used the pointer that got stomped on.
Data breakpoints are not perfect either - you will also get a hit when legitimate code changes the same address, and have to have filtering to skip such false positives.  They obviously do not directly help make the unwanted situation occur often enough for convenient debugging, but they might nonetheless be useful.  (Perhaps you have a bug that regularly stomps on the pointer, and other code that regularly writes to the pointer with valid data.  The failure might only happen once a week by coincidence in timing, while the incorrect write to the pointer might occur far more often.)
So data breakpoints are not always helpful, but I have used them in similar circumstances and they are often a tool people don't know much about.