.NET/VS 2008 Debugger question

[wraith808]

An interesting question about the veracity of information seen in the debugger.

Given this snippet of code

Code: C# [Select]

1. // Get first key //
2.             int? keyEDISecurity = this.WorkQueue.GetNextWorkItem();
3.  
4.             // Done? //
5.             while (keyEDISecurity != null)
6.             {
7.                 try
8.                 {
9.  
10.                     ...
11.  
12.                     // Write changes //
13. -->                List<ISNLEditableObject> changedRows = this.WorkQueue.GetChangedRows((int)keyEDISecurity);
14.                     this.Writer.Write(changedRows, WriteFlags.Transactional);
15.  
16.                     ...
17.                 }
18.                 catch (Exception ex)
19.                 {
20.                     string errorMessage = "There was an exception processing KeyEDISecurity " + keyEDISecurity.ToString() +
21.                         " - " + ex.Message;
22.  
23.                     // output error info //
24.                     Console.WriteLine(errorMessage);
25.                     EDI.WriteLog(errorMessage);
26.                 }
27.                 finally
28.                 {
29.                     // Remove all data for the KeyEDISecurity from work queue cache //
30.                     this.WorkQueue.RemoveData((int)keyEDISecurity);
31.                 }
32.  
33.                 // Get next work item //
34.                 keyEDISecurity = this.WorkQueue.GetNextWorkItem();
35.             }

Before the line with the -->, the changedRows is null, as it should be.  It then goes out of scope, as you get the next work item.  You then come back in, and before the line with the --> if you access changedRows, it should be again null, as it hasn't be declared.

If you break and edit, then, as you expect, you can't access changedRows, because it's gone out of scope, and not been declared yet.  If you evaluate it (either by mouseover or using the immediate window), you have access to the changedRows from the previous iteration of the loop.  WTH?

Anyone seen this?  It doesn't affect the program as it seems to act correctly in code, but the debugger issue caused a waste of time since it wasn't behaving as expected.

Thoughts?

[f0dder]

I don't know enough to answer the question at the language level, but as I'm sure you know, block scope and object lifetime don't have much to do with eachother in .NET. So it's perfectly valid for the object to be alive - perhaps it's even because of the debugger holding a reference it's not getting GC'ed?

But I'd definitely not expect the debugger to show the variable in 'locals' before it's in scope (the same goes for 'watch') - but perhaps there's something tricky about .NET variable scope?

You might want to make a StackOverflow post on this and hope John Skeet or somebody can come up with a good answer - and if you do, please post a link here.

[wraith808]

I already did. http://stackoverflow...out-of-scope-objects

Someone answered it, and the answer does seem feasible, even though it's mind-boggling.

The really squirrelly thing that's bothering me is the fact that in the code (break and edit) the object shows as null, and you can't access any of the properties via intellisense.  But in the watch window and in the immediate window, you can access all of the properties, and it's of the object that's gone out of scope.  It didn't cause any problems because I was declaring/instantiating it later in the scope, but that shows me that there's *something* weird about it because if it was actually declared the compiler would have complained about the re-declaration.

[Eóin]

Interesting explanation there on StackOverflow. Where you debugging a Release build?

In C++ there can sometimes be almost no obvious correlation between source code and machine code after the compiler is through optimizing.

[wraith808]

No, it was a debug build, with optimization turned off.  It makes sense that to do some of the things that the debugger does, it violates the rules of the compiler, though I never really thought about it in that manner.

[f0dder]

This is why value of changedRows is preserved, even though, according to language rules, it must be destroyed (when it goes out of scope) and created again (when it is declared).

-http://stackoverflow.com/questions/4228501/does-the-vs2008-debugger-hold-on-to-out-of-scope-objects/4228581#4228581

Nit-picking: the language rules don't say the object must be destroyed when it goes out of scope - but when there's no more references to it. And because .NET uses a tracing GC, it furthermore doesn't guarantee this happens as soon as the last reference is removed, but "at whatever time the systems believes it's right to take out the trash".

This is why finalizers in C# are pretty much useless for anything but "Uh oh, moron, you forgot to Dispose" diagnostics

[wraith808]

So would that give any less veracity to the answer?  Or is that just something that should be noted on the answer?

[f0dder]

So would that give any less veracity to the answer?  Or is that just something that should be noted on the answer?

-wraith808 (November 20, 2010, 09:04 AM)

The rest of the answer sounds pretty good to me - but it'd still be nice to see what one of the language experts has to say