>>>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.

You could compile in unsafe mode and get a fixed pointer that way which solves garbage collection part of the problem. But, end of the day, I would still just simply use a property with a breakpoint on the setter. Simple....


>>>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.txt
>Line 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."