1

Why is it that breakpoints are always tied to lines, and optionally to state? Why can't we have breakpoints that are tied solely to state or state changes, and not to lines? How does this relate to breakpointing on a whole class?

We can typically suspend execution at an arbitrary point -- why can't we have our IDE's suspend execution when a certain state is hit, wherever the execution point is? How would we implement these breaks? (I assume that by the time the state change has triggered a suspension the code being debugged may have continued).

I started thinking about this recently, when I wondered if there might be a way of suspended execution when a certain file was accessed, and thought also about how my debugging process often splits into two components: targeted breakpointing and global searches based on hunches about the code is behaving.

Due diligence: related post here, at least.

addition: my particular immediate interest happens to be in c# on visual studio -- with Mark Wilkins' link below I managed to track down "data breakpoint" setting in visual studio, only enabled while debugging C++ native code.

Community
  • 1
  • 1
Tim Barrass
  • 4,813
  • 2
  • 29
  • 55

2 Answers2

1

It is possible to set breakpoints such that it stops in the debugger when a value at an address changes (data breakpoints). I believe that in GDB it is called a watchpoint. And in Visual Studio, you can set a data breakpoint as well (menu Debug \ new breakpoint).

Mark Wilkins
  • 40,729
  • 5
  • 57
  • 110
  • great link, thanks -- "gdb does software watchpointing by single-stepping your program and testing the variable's value each time, which is hundreds of times slower than normal execution. (But this may still be worth it, to catch errors where you have no clue what part of your program is the culprit.)" Equally I guess you *could* single step and check to see whether a number of flags had been raised, and provide a mechanism for external code to set those flags? – Tim Barrass Dec 16 '10 at 15:31
  • 1
    I haven't used GDB enough to have dealt much with the speed issue (I spend most of my time on Windows and use Visual Studio most days). But I agree that the slowness is worth it if it can help find some obscure problem. The difficult part is when it is a concurrency/timing problem and the added breakpoints cause enough of a change so that the problem doesn't happen. – Mark Wilkins Dec 16 '10 at 15:46
1

"Data breakpoints" are often requested for VS, but never seem to be high enough priority to implement in the CLR. Perhaps go upvote it here:

http://connect.microsoft.com/VisualStudio/feedback/details/333647/data-breakpoints-in-managed-code

Brian
  • 117,631
  • 17
  • 236
  • 300
  • 1
    Voting is closed, but a tip included -- "anaged Data Breakpoints is something we have wanted for a long time. There is key infrastructure in the CLR that is missing for us to implement this. .... In the meantime, what most people do as a workaround this is use properties to access their fields and then set breakpoints in the setter of the property. " – Tim Barrass Dec 16 '10 at 20:08