Other Software > Developer's Corner

.NET/VS 2008 Debugger question

(1/2) > >>

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

Given this snippet of code


--- Code: C# ---// Get first key //            int? keyEDISecurity = this.WorkQueue.GetNextWorkItem();             // Done? //            while (keyEDISecurity != null)            {                try                {                     ...                     // Write changes //-->                List<ISNLEditableObject> changedRows = this.WorkQueue.GetChangedRows((int)keyEDISecurity);                    this.Writer.Write(changedRows, WriteFlags.Transactional);                     ...                }                catch (Exception ex)                {                    string errorMessage = "There was an exception processing KeyEDISecurity " + keyEDISecurity.ToString() +                        " - " + ex.Message;                     // output error info //                    Console.WriteLine(errorMessage);                    EDI.WriteLog(errorMessage);                }                finally                {                    // Remove all data for the KeyEDISecurity from work queue cache //                    this.WorkQueue.RemoveData((int)keyEDISecurity);                }                 // Get next work item //                keyEDISecurity = this.WorkQueue.GetNextWorkItem();            }
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.com/questions/4228501/does-the-vs2008-debugger-hold-on-to-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.

Navigation

[0] Message Index

[#] Next page