>>Understood. Though I imagine one could walk the stack and (through trial
>>and error) determine the location of the reference to the variable portion
>>which moves around from time to time, and then set a breakpoint there
>>(instead of or) as well.
>Sounds like Catch 22. You wouldn't know when to look ......
At some instance point you get the physical location of the value, such as passing data to communicate with external DLLs. And unless .NET is always making a copy for that operation, you'll know the true source.
By then setting a breakpoint on that memory location from inside a debugger, you can look at the call stack of the thing that accessed it, even traversing the eip/rip backwards to find out the assembly instructions leading up to its use. You'll be able to determine from where it came by trial and error.
Once you determine the one-level-back-parent-structure that has a pointer to the actual data, you can begin to monitor it through normal application use and see if it periodically also moves. I would be surprised if it does outside of it's scope and before garbage collection.
Would be an interesting feature to have.
>>Still, perhaps the better solution is just switch to Java and be done with it. :-)
>>Open source, copyleft protected:
http://openjdk.java.net/>>Just what the doctor ordered.
>
>Sounds like a drastic solution :-} TBH I've never really missed being able to set a
>data breakpoint. And I'm pretty sure that if there was a viable way of providing that
>functionality in managed code then MS would have done it...
I don't know. I've developed a way to do it. It's very straight-forward:
Lines 325-334:
https://github.com/RickCHodgin/libsf/blob/master/documentation/vvm/OBED/obed_draft_0.60.txtLine 532, 534-541:
https://github.com/RickCHodgin/libsf/blob/master/vvm/core/vvm/vvm_structs.h>Does Java have that anyway ?
Yes. You can break when data changes. See NetBeans debugger help, page 9, last paragraph:
https://netbeans.org/project_downloads/usersguide/nbfieldguide/Chapter5-Debugging.pdf"You can also set breakpoints on other situations, such as the calling of a method, the throwing of an exception, or the changing of a variable's value."