views:

137

answers:

8

I have a class in C# that is acting weird. Whenever I perform some action, a property that happens to be a list loses a member. I have no idea why it's doing this. So what I'd like to do is set up a Visual Studio breakpoint that will pause the program the moment this value changes. A conditional breakpoint would not work in this scenario, since I have no idea what is removing this breakpoint.

To put it another way, I want my program to stop the moment myList.Count evaluates to a new number.

Any ideas on how to do this? Thanks!

+2  A: 

Subclass List<t> with your own class, then override Count (or Add/Remove) and add a breakpoint in the method you create.

EDIT: As mentioned in comments, this would require a great deal of effort since the Add and Remove methods aren't virtual; a complete rewrite of the methods would be needed.

Also, subclassing Collection<t> would apparently be a better solution (though I can't discern a reason why since Add/Remove aren't virtual members for Collection<t> either; comments?).

Michael Todd
You can't override Add/Remove methods because they are not virtual. You can hide this methods and provide new versions, but in this case you should change all usage from List<MyType> to MyList<MyType>
Sergey Teplyakov
This would be much more doable if you replace `List<T>` with `Collection<T>`.
SLaks
+1  A: 

This is not possible in C# or any of the other .NET languages due to CLR limitations. The Visual Studio native code debugger supports data breakpoints (link) for C++ code which do exactly this but this is not supported for managed code. You could try to break on or intercept Add and Remove method calls on the collection as suggested in the other answer to this question.

Richard Cook
A: 

You can set data breakpoints in visual studio but this is going to be difficult to do for managed code, as the garbage collector may move the object around. That said, you may still be able to pull it off. You will have to enable native debugging for your process. Load SOS in the immediate window and use !DumpObject to find the address of the backing store for the Count property. Using this address, create a new data breakpoint with this address and then continue and trigger the issue.

Logan Capaldo
I have never tried this as it relates to debugging, but could you not pin the object to prevent the GC from moving it around?
Brian Gideon
+1  A: 

Find all usages for this particular property and add breakpoint to all lines that removes elements from this list.

Or you may create your own IList implementation and set breakpoint to Remove method (you can't subclass List without changing all you clients, because List::Remove isn't virtual).

Sergey Teplyakov
I went with the "Find all usages" suggestion. I was hoping for an easier solution, but I understand why it's not possible in Visual Studio.
Jason Thompson
A: 

this may sound too out of the way or complex but can you use timer/background thread to keep testing the count value and do a Debugger.Break() whenever it finds the value different from its previous instance.

An interesting idea, however; it would not give me the results I'm looking for. I want to know the exact line that caused the change.
Jason Thompson
+1  A: 

I'm assuming Visual Studio is IDE.

Set a breakpoint, right click it, select condition, type myList.Count, and choose Has Changed.

Chris Martin
"A conditional breakpoint would not work in this scenario, since I have no idea what is removing this breakpoint."
Jason Thompson
But that would stop execution and you can inspect the call stack for the offender. :)
Chris Martin
It would, however; I would have to know where to set the breakpoint in this scenario. I think conditional breakpoints are great and use them all the time, but in this scenario at the time I wrote this question, I had no idea what line of code was causing the issue. I appreciate your thoughts on this question however. Thanks!
Jason Thompson
+1  A: 

This is maybe more of a question than an answer, but you can step into Framework code when debugging, provided you set up your Visual studio that way. It could be that you can then put the breakpoint into the actual List implementation.

flq
+1  A: 

What about swapping out List<T> for ObservableCollection<T> and listen for the CollectionChanged event? It implements the IList<T> interface so there should be enough overlap in available methods to result in syntax and semantic compatibility.

Brian Gideon
This is a great idea! I can't believe I didn't think of using an ObservableCollection earlier. When CollectionChange is invoked, is there a way to trace the stack back to the line of code that made the change?
Jason Thompson
@Jason: Yeah, I think so. Since the events are raised synchronously the code that initiated the change should appear on the call stack somewhere right?
Brian Gideon
Makes sense to me. I'll try this out next time I run into a similar situation. Thanks!
Jason Thompson