in Search

Do you Twitter? Follow us @CodeBetter

Jeffrey Palermo [MVP]

Software management consultant and CTO, Headspring Systems

Debugging tip: But that can't happen!! Ah, but it did. Ensure you are looking at the right object - level 300

Debugging can be easy or hard. It's easy if you have an easily reproducible error. This morning I wrestled a bug where a screen just stopped showing data. Nothing. Zilch.

When I debugged through, I watched every piece of data get properly set to labels in my Winforms view that were visible, but the screen shows up without the data!! What gives?

Ultimately, I was looking at the wrong instance of my screen/view.

Here's a debugging tip to use if you watch the code executing properly but it still doesn't work in the end:

Make sure you are looking at the right object.

In the debugger, set a breakpoint in the constructor and ensure you are watching the right instance. In the immediate window, use the hashcode to track the instance:

this.GetHashCode()
34169857
this.GetHashCode()
61248560

This way, you can clearly identify the object.

Published Apr 10 2007, 12:04 PM by Jeffrey Palermo

Comments

Derik Whittaker said:

Been, there, done that.

So, how long did it take you to realize you were looking at 2 different object? I know i have spun my wheels for 20+ minutes before.

Derik

# April 10, 2007 2:59 PM

Kirk Jackson said:

Hi Jeffrey,

I also use Object IDs in the debugger for the same thing, though I'm not sure how well they work from the immediate window. Just right-click a variable when debugging, and create and Object ID:

http://msdn2.microsoft.com/en-us/library/ms164903(vs.80).aspx

Kirk

# April 10, 2007 3:47 PM

Ayende Rahien said:

Oh boy, how this can trip you.

I had an issue where I was caching stuff that I really really shouldn't, and I couldn't for the life of me figure out what was happening.

The Debugger's Object ID told me eventually that something was wrong, and then it was tracking down why, at which point it boiled down to "smack forehead" time.

# April 10, 2007 5:04 PM

You shouldn't totally rely on GetHashCode - sure the default behaviour will get you this but any object that overrides .Equals should also override .GetHashCode with a mechanism that will generate the same hashcode for two objects that .Equals each other.

Otherwise you'll never find it in a Dictionary<T>

[)amien

# April 10, 2007 6:14 PM

Dave Laribee said:

There is that school of thought that says "always override ToString() as that's what shows up in the Locals/Watch for the object entry" and I guess you could implement (default) as this.GetHashCode().ToString()... minus Damien's point.

I think it's generally good wisdom but I tend to get lazy on this point.

# April 10, 2007 7:57 PM

Martin Clarke said:

Rather than using the immediate window or the ToString for that. You can also set a debuggerdisplay attribute on the offending class (from System.Diagnostics.

[DebuggerDisplay("Test = {this.GetHashCode()}")]

public class foo

{

private int bar;

public int Bar

{

get { return bar; }

set { bar = value; }

}

# April 27, 2007 3:38 PM

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate.