Conditional Breakpoints – A Cautionary Tale

You know the scene – you have a loop that iterates through loads of records but something strange happens when  Widget.Property = “Banana” or somesuch. “What the devil is going on?” you mutter to yourself, and you set a conditional breakpoint on an appropriate line to see what is happening when the property is set in this way.

Breakpoint set, condition set, and off you go.

However, now, something really strange starts. Object properties are changing when you least expect it and you start to doubt the very fabric of the universe (or at least the .NET Framework runtime). Widget.Property equalled “Apple” a minute ago, and now it equals “Banana” for no apparent reason and you really can’t get your head around it. A PC reboot, and a quick Google-ing doesn’t help. Your mind wanders further.. maybe a virus? A problem with the PC’s memory? Surely not. Everything else seems to be fine.

In desperation you remove the breakpoint and.. lo and behold.. the problem goes away. Or, at least, the original problem comes back. What the hell?

The problem lies in the condition on the conditional breakpoint. I had set my condition to Widget.Property = “Banana” -  note that I had accidentally used one “=” , not two. The upshot of this is quite logical once you sit back and think about it – just prior to the line with the breakpoint on it being executed, the condition is executed and the boolean result determined. If the boolean result is true, the breakpoint stops execution, if not, it continues.

So rather than checking if Widget.Property equalled “Banana” I was in fact setting Widget.Property to “Banana” on every iteration round the loop.. and this is why I couldn’t work out what the hell was going on.

And note that this condition is executed when the line with the breakpoint on it gets the “focus”. So you haven’t even stepped past the point where the breakpoint is set when the weird things happen. I wasted an hour on this today…

An example, below:

class Program
{
static void Main(string[] args)
{

List<Person> people = new List<Person>();
people.Add(new Person(“Mr A”, 36));
people.Add(new Person(“Mr B”, 37));
people.Add(new Person(“Mr C”, 38));
people.Add(new Person(“Mr D”, 39));

for (int i = 0; i < people.Count; i++)
{
Person iPerson = people[i];
Console.WriteLine(iPerson); //  <– Put cond. breakpoint here
}
Console.ReadLine();

}
}

public class Person
{
public string Name { get; set; }
public int Age { get; set; }

public Person(string name, int age)
{
this.Name = name;
this.Age = age;
}

public override string ToString()
{
return string.Format(“{0} ({1})”, this.Name, this.Age);
}
}

Run the program and you get a list of people and ages.
Now set a breakpoint on the line indicated, and set it to break when  iPerson.Name = “Mr B” (with 1 “=” sign)

Run the program again and note that, first of all the breakpoint is never trigged, and second of all you just get a list of Mr.B’s but all with different ages.

So.. beware this one, fellow developers. It may just catch you out one day…

Advertisement