How to setup Conditional Watchpoints?

[stmcoder]

I'm trying to track down a memory corruption bug in my code. I can setup a Watchpoint for a specific variable (Expression to watch: *(uint32_t*)0x20024840), and get the debugger to stop at a breakpoint whenever the variable is written to (good!).

However, my problem is that 99% of the time, it's a legitimate/intended write, and I'd like it to NOT break at those locations so I can focus on the problem area.

I've tried using the "Conditon:" field in the breakpoint property in 3 different ways:

1) Ignore breakpoint if at a specific address:  $pc != 0x80201cc

2) Ignore the breakpoint if in a specific function:  !$_is_in_function("my_func")

3) Ignore the breakpoint if the value being written to the variable is within a range:  *(uint32_t*)0x20024840<3000||*(uint32_t*)0x20024840>4000

In all 3 cases, it seems to have no filtering at all. I hit all the breakpoints any time the variable is written to no matter what I write on the "Conditon:" box. Is my syntax wrong? Do I need to enable something?

Any hints on how to get this to work? I do have optimizations set to None

[Ghofrane GSOURI]

Hello @stmcoder 

Could you please share the exact condition syntax you are using in your watchpoint or breakpoint? Reviewing the specific expression will help me check for any syntax issues and provide more accurate assistance.

THX

Ghofrane

[stmcoder]

Expression:
*(uint32_t*)0x20024840)

Condition:
$pc != 0x80201cc
!$_is_in_function("my_func")
*(uint32_t*)0x20024840<3000||*(uint32_t*)0x20024840>4000

These are exactly what I'm putting into the watchpoint fields.

[Ozone]

This is tricky, as there is no fixed "breakpoint location".
If you think it is a memory corruption issue, you can try to surround the definition of the variable in question with dummy variables. Do not touch them at runtime, but watch them as well.
Similiar to many runtime stack check implementations.

If it is really a memory corruption issue, which is most likely a stack overflow, those "guard" variable would be affected as well, if not first. 

[stmcoder]

Not a bad idea, but adding new variables does technically change the memory layout, and I kind of like that right now I have an exact build that has a repeatable issue. Are you saying that conditions won't work on a watchpoint because there is no fixed "breakpoint location"?