views:

84

answers:

1

I have a bool variable which should be true, but is sometimes set to false. I have set a memory breakpoint to see what is changing that. To my surprise, the breakpoint did not hit, but the variable went to false again.

What could change the memory without memory breakpoint catching it?

+3  A: 

A few thoughts.

  1. If you pass the bool value into a kernel function and THAT is changing it (or perhaps a kernel function call is overwriting memory because it is called incorrectly) then that won't fire a data breakpoint.

  2. If you are using multiple processes and another process, that isn't being debugged, writes to that memory location then you the breakpoint won't get triggered.

  3. (Edit) As pointed out in the comments a DMA into the memory the hardware breakpoint is on will also not get picked up.

My guess is that you aren't checking a buffer size appropriately somewhere and you are getting hit by (1), perhaps when reading data from a file?

Goz
Exact hit. The culprit was call:static bool screenSaverEnabled; SystemParametersInfo(SPI_GETSCREENSAVEACTIVE, 0, Additional lesson learned: Beware, there is bool and BOOL.
Suma
For completeness I suggest adding one more possibility into the answer: DMA transfer (like when using overlapped I/O) can change memory out of CPU control.
Suma
You are quire right Suma. I thought I had added DMA on there! That has bitten me more than once on MIPS platforms ;)
Goz