jaredpar's WebLog : Debugging

Why is LINQ absent from debugger windows?

Jared Parsons — Wed, 26 Aug 2009 15:00:00 GMT

As the owner of the VB.Net portion of the overall debugging experience, I frequently hear the request from customers to add LINQ support into the Watch / Immediate and Locals window. Virtually every other type of expression is available in the debugger windows so why leave one of the most popular ones out?

Quick Diversion: the specifics of this article are written from the point of view of the VB.Net expression evaluator. However, the limitations blocking LINQ support (in both the architecture and overall design) are very similar between VB.Net and C#.

As usual, the primary issue is cost and the cost for LINQ in the debugger windows is very high. To understand why the cost is so high though, we must start by getting a better understanding how a language service interacts with the debugging services of Visual Studio and the general philosophy around compiler features in the debugger.

Languages in Visual Studio typically provide the following major components to support the debugging experience.

Expression Evaluator (EE): This is the language specific component which provides all of the data used in the watch, locals and immediate window, data tips, conditional breakpoints and several other components. It’s primary input is an expression in string form which is converted to a value (typically an ICorDebugValue instance) and outputs a COM object capable of inspecting that value to the core debugger [1]. Everything typed into the debugger windows goes through the EE.

This component lives in the MTA of Visual Studio and has almost no interaction with the UI / STA thread.
ENC Service: This is the component which is the work horse of ENC operations. It provides rude edit detection, metadata differencing and metadata + IL generation .

This component lives in the main STA of Visual Studio

The important thing to understand about the expression evaluator is that it’s purpose is primarily to provide an expression evaluation and data inspection service. How expression evaluation works is an article in itself but suffice it to say that it converts the string to a very low level AST then walks the nodes bottom up and evaluating the expressions using the ICorDebug APIs. The EE component has no UI and is simply a data provider for the core debugger services.

The design philosophy for Both VB.Net and C# is to have the highest level of fidelity between expressions evaluated in the EE and the actual running program. To do otherwise would lead to extremely confusing results for users. When spec’ing feature support in the VB.Net EE we start from the point of 100% fidelity, determine the problems with this design (if any) and then start the difficult process of making compromises.

LINQ expressions are very different than any other expression previously allowed in the EE window because of the features interaction with metadata. All LINQ expressions require the generation or manipulation of metadata to support the underlying lambda and/or closure. Adding support for this is one of the biggest hurdles to getting LINQ (and other features) into the EE.

Evaluating a LINQ expression is actually much closer to an ENC operation than a traditional EE one.

Currently the EE’s have no capacity for generating metadata, only interpreting it. Operations which mutate or generate metadata have traditionally only been allowed via the ENC service. Getting LINQ to work in the EE with true fidelity would require at least a minimal amount of ENC feature work.

Without getting into too much detail, lets enumerate the new major features necessary to evaluate a LINQ expression in the EE with true fidelity to the running program. To simplify things, we’ll start by assuming there is no other LINQ expression used in the current method and the method is only being executed at most once at any given time in the process.

A metadata generation service to support the backing for closures and lambda expressions
Convert expressions typed in the EE into IL [2]
ENC support for metadata to push the new metadata for closures and lambdas into the currently executing assembly
ENC support for method body IL to remove lifted variables from the current method and redirect the references inside the closure

Issues #1 and #2 are for the most part internal architecture issues and can be solved via normal processes of code base refactoring and adding new features to an existing component. I don’t mean to imply these problems are cheap (in fact they are relatively expensive) But fixing these is somewhat of an understood quantity.

Issues #3 and #4 are where the problems start. As implemented EE’s do not have capability to create or modify metadata in the running process (that is the job of the ENC service). EE’s do have access to the underlying CLR ENC APIs so it is possible to implement ENC operations in the EE. It’s just simply not been done yet.

Wait! Why not reuse our ENC implementation in the EE? Unfortunately the ENC service is currently tied heavily to our in memory IDE compiler and many other IDE / STA features. It in fact lives in a completely separate DLL, separate COM apartment and works on a different symbol table than the EE.

More fundamental though is that it’s designed for a completely different purpose. ENC is designed to track edits in live code, determining the differences and applying them to the running program. The hypothetical EE feature would be tracking expressions that modify a running DLL for which code is not guaranteed (and not likely) to be available and applying the difference to the running program. There are some similarities but the differences are significant enough to make code reuse have limited value.

Some people may wonder why it’s necessary to implement #4. Couldn’t we just avoid removing the variable from the current method and make the feature cheaper? This is possible but it would cause a significant fidelity difference in the feature. Any mutations of the local variable within the LINQ expression would not be visible on the stack frame as it would if the LINQ expression was present in the original program.

It’s easy to think of this ENC in the EE as just the same type of cost as #1 and #2 (in many ways it is). However taking advantage of the CLR ENC APIs in the EE also means that we inherit it’s limitations as well. ENC as as implemented in the CLR has many limitations which fly in the face of LINQ. In particular the following ENC limitations present major problems (ENC limitations reference).

Cannot add members to a value type. This prevents evaluating LINQ when stopped in a value type method
Cannot remove locals from a function. This is an implementation of LINQ but we could work around this problem by changing the IL to simply no longer accessing the local variables.
Cannot change anything in a generic type. This prevents evaluating LINQ when stopped in a generic type.
Cannot specify an initial value for newly added fields.
Allowable ENC operations differ between the top of the stack and operations elsewhere within the stack
Modification of a non-top stack frame cannot significantly edit the current function call. So if a LINQ expression captures a variable used in that call (think ref passing) it would likely be unable to be evaluated.

So even if we implemented everything possible on the language service side the resulting feature would be limited in several impactful ways. Additionally these limitations are somewhat orthogonal to the current limitations EE’s face and would require a bit of user education. And this is only for the most basic LINQ feature under unrealistic scenarios.

Lets now consider the problems of evaluating a LINQ expression when the current method already contains a LINQ expression that lifts at least 1 variable. Evaluating a new expression at the same scope would require the modification of the current closure to maintain fidelity as opposed to generating a new one. This brings along with it a couple more problems.

A lambda expression which uses 2 variables, 1 of which is captured in an existing lambda expression. To maintain fidelity we would have to modify an existing closure signature to contain the new variable.

Often times generated closures are generic so we would run straight into ENC limitation #3. Additionally we would need the newly added field to have the same value as it has in the current method which runs us into ENC limitation #4. Now also consider that a closure instance can live much longer than the method in which it was created. For those closures no stack value is available so what value should we give fields in that instance? Ideally it should have the value of the variable at the point the method exited but realistically that’s not possible.
A lambda expression which uses 1 variable in a method where an existing lambda expression captures that same variable and another. To maintain fidelity we would have to know about this and fake capture the second variable as well.

Now consider all of the problems above and consider the scenario where there are multiple threads and multiple instances of the current method active in the program. How to determine which closure instance belongs to which thread, and just as important which stack frame on which thread, with respect to initializing values?

None of the issues are an unsolvable problem but they do represent a significant cost to the feature. And once again even if we added all of these features to the EE, ENC limitations would significantly limit the usefulness of the resulting feature.

Does this mean that LINQ, or any future metadata requiring expression, will never be added to the debugger window? Absolutely not. We’ve just hit the difficult stage of making compromises on the level of fidelity in the feature. If you back off of true fidelity in a few small ways the resulting feature, while still very expensive, is significantly cheaper and removes many of the limitations imposed by ENC. This hypothetical feature will be discussed in my next article.

[1] For those interested the returned interface is IDebugProperty2

[2] Right now expressions are converted to a tree form slightly above IL and they are interpreted using the ICorDebug APIs. Converting all the way down to IL requires a lot more work

Debugging F# list's

Jared Parsons — Wed, 10 Sep 2008 15:00:52 GMT

One of the lacking's of the latest F# CTP is debugger visualization support for the built-in list types. Viewing a list in the debugger is decidedly tedious compared to the mscorlib collection classes. Take the following quick code sample

module Main =
    do
        let l1 = [0..4]
        let l2 = List.map (fun a -> a.ToString()) l1
        let l3 = new System.Collections.Generic.List<int>()
        List.iter (fun i -> l3.Add(i)) l1
        MainModuleTemp.Main()   // Breakpoint here

Hit F5 in a F# console application and you'll get the following display.

Notice how the elements of the mscorlib List<> are immediately visible. Getting to the data in a F# list is possible but it takes a lot more clicks than the mscorlib version. This doesn't appear to be an oversight on the F# team either. The expansion of mscorlib List<T> is controlled by the DebuggerTypeProxy attribute on the class definition. If you fire up Reflector and dig into Fsharp.Core.dll and navigate to List<T> you'll notice it indeed has a DebuggerTypeProxy entry which is well formed and points to ListDebugView<T>.

ListDebugView<T> is essentially identical to the one for mscorlib List<T>. So what gives? The bug appears to be in the accessibility of the constructor. Even though it's not explicit in the documentation of DebuggerTypeProxy, it appears that the target type must have a single argument constructor which is public. The one for ListDebugView<T> is internal.

Normally this would be an easy enough problem to work around. Add an assembly level attribute of type DebuggerTypeProxy pointing to List<T> and a modified version of ListDebugView. Unfortunately that will not work in this case. The debugger will prefer DebuggerTypeProxy instances added directly to a type over ones defined at an assembly level.

That is, except for two cases. The debugger will give precedence to assembly level attributes which are defined in an assembly named autoexp.dll and placed in one of the following two locations

Visualizers folder for the current user. One my machine it is C:\Users\jaredp\Documents\Visual Studio 2008\Visualizers
Devenv global visualizer folder. C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\Visualizers\Original

If you navigate to either of these directories you will find both the default autoexp.dll and the source code used to compile it. It's got quite a few entries you may want to add in a modified version. Adding a new ListDebugView<T> here is possible but lets do it in F# instead.

Since autoexp.dll has predecence all we need to do is build a new version which has the appropriate debugger attributes for the F# collections. Fire up a new class library project named autoexp and have it output to either of the directories listed above. Below is a sample definition to get you started.

#light
open System.Diagnostics

module Main =
    type ListProxy<'a>(l:List<'a>) =
        [<DebuggerBrowsableAttribute(DebuggerBrowsableState.RootHidden)>]
        member this.Items = 
            Array.of_list l
            
    [<assembly: DebuggerDisplayAttribute("{Length}", Target=typeof<List<int>>)>]
    [<assembly: DebuggerTypeProxyAttribute(typeof<ListProxy<int>>, Target=typeof<List<int>>)>]
    do 
        ()

Don't be alarmed at the typeof<List<int>>. The visualizer will work for any generic binding of List<T>. In fact, reflector confirms that this attribute will be emitted with the type pointing at the unbound List<T> instead of List<int>. My lack of F# skills is failing me as to why. I'd love to cry bug but I've found crying bug at a compiler is usually ... wrong.

In either case, once you build this and place in the appropriate folder, you should find the visualizations for List<> much more accessible.

Disabling JIT optimizations while debugging

Jared Parsons — Fri, 29 Aug 2008 15:00:10 GMT

If you've ever been debugging a managed app, only to be unable to evaluate any of the locals or parameters because the code was "optimized", check out the article below. It shows a quick trick to disable optimizations by way of a .ini file. This is great because it doesn't force you to recompile the application and takes only seconds to implement.

The short version is create an .ini file (i.e. myapp.ini) with the following contents.

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

This has really saved me time debugging recently. It's been blogged about by several others but given that I've had to search for this solution 3 times in as many weeks, I figured blogging about it would make it easier to find next time :)

http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx

Debugging PowerShell

Jared Parsons — Mon, 15 Oct 2007 18:46:22 GMT

Debugging PowerShell can be extremely frustrating because it often turns into a session of debugging your own thought process. Often when I hit a PowerShell script issue I find myself feeling like everything is right and I'm just missing something basic. IMHO, this is because I spend the majority of my day programming in compiled languages and don't completely come out of that box when I'm programming in PowerShell.

For instance the other day I added one of Lee Holme's scripts to my default profile. The script is used to create a Generic object inside of PowerShell.

http://www.leeholmes.com/blog/CreatingGenericTypesInPowerShell.aspx

The syntax is very clean. It is the same as new-object but requires the additional type parameters.

$PS>new-genericobject Collections.Generic.List int
$PS>

The only problem was I couldn't get the script to return an object. I tried a couple of operations like passing the output to get-member and seeing what exactly I was creating. I kept getting errors like "No object has been specified ...". My mind kept saying "It's there, it's non-null, why doesn't it have any members!!!".

Frustrated I turned to some internal aliases and eventually Lee helped me out. Nothing above is in error. The problem is PowerShell will unroll collection classes. In this case I've created an empty collection so there is nothing to output or pass to get-member. My issues is that I kept thinking it terms of compiled languages instead of PowerShell's collection unrolling semantics (which I will add, I quite like).

Sadly any other object creating would have quickly lead me to this solution

C:\Users\jaredpar\winconfig\PowerShell> new-genericobject collections.generic.Ke
yValuePair int,int

                                    Key                                   Value
                                    ---                                   -----
                                      0                                       0

Another way to figure out this problem would be to bypass the collection unrolling in pipelines and directly specify the object to get-member.

C:\Users\jaredpar\winconfig\PowerShell> gm -inputobject $col


   TypeName: System.Collections.Generic.List`1[[System.Int32, mscorlib, Version
=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
...

.Net Framework Source Code

Jared Parsons — Wed, 03 Oct 2007 21:58:04 GMT

If you haven't heard the news yet, you can read the full article on ScottGu's Blog.

In summary Microsoft has released the source code for the .Net Framework in such a way that you can step into the Framework while debugging. IMHO this is great for users because it allows us to get a lot of insight into parts of the API that are tricky or not well documented.

Take a look at his blog for the full details of hooking this up into the debugger.

Customizing Displays in the Debugger for System Types

Jared Parsons — Fri, 28 Sep 2007 23:32:00 GMT

We've heard feedback from several customers regarding the way certain types are displayed in the Debugger. Many of the displays exist to maintain the user experience between versions of Visual Studio. We constantly evaluate if this is the correct choice for a given version of the product.

Starting with VS2008, you don't have to wait for us any longer. In VS2008, VB added full support for many of the debugging features it lacked compared to C# in 2005. In particular we've added full support for the DebuggerDisplayAttribute.

By attributing a class or member with this attribute you can control how it is displayed in the debugger. For each column (name, value and type) you can provide an alternate string or expression to display.

The best part about this attribute is you can target types that exist in different libraries. You don't even need the source for them. One of the members in the Type field which species the target type. Customizing a type in a separate library requires slightly more work than customizing a type you have the source for. For a source project you can just apply the attribute directly to the type or member and it will display. For a type in another library you need to do the following.

Define a class library and include all of the DebuggerDisplayAttribute you want. Make sure to apply the attributes to the assembly and specify the Type member. Ex.

<Assembly: DebuggerDisplay("{ToString}", Target:=GetType(Guid))>

Place the built library under the folder "Visual Studio 2008\Visualizers" which is under your my documents folder.

After doing this any Guid type will now show up as the actual Guid String ("10f3c4eb-7c0f-41b1-ae83-8838ff2f4f70") instead of {System.Guid}

DebuggerNonUserCode and Properties

Jared Parsons — Wed, 29 Aug 2007 19:45:39 GMT

DebuggerNonUserCode is an attribute that tells the debugger that the target item is not code typed by the user. It can be added to classes, structs, methods, constructors and properties.

The benefits of this attribute is that it allows the compiler and designers to distinguish user code from generated code. As such the debugging experience can be altered. When this attribute is present and "Just My Code" (JMC) is on the debugger will not step into or break in these methods for normal cases. Instead it will treat it is if it was a call to a framework assembly.

However if you type code like the following you won't get the behavior you probably expect.

    Class C1
        Private m_f1 As Integer

        <DebuggerNonUserCode()> _
        Property P1() As Integer
            Get
                Return m_f1
            End Get
            Set(ByVal value)
                m_f1 = value
            End Set
        End Property
    End Class

While investigating a recent bug I found that I could step into the get/set method of properties annotated with DebuggerNonUserCode. The reason why is a bit unexpected. The attribute is applied to the property, not the get/set method. The debugger will only check the actual methods involved. It doesn't special case properties in any fashion. If you want to get the expected behavior, you have to annotate the get/set method directly.

    Class C1
        Private m_f1 As Integer

        Property P1() As Integer
            <DebuggerNonUserCode()> _
            Get
                Return m_f1
            End Get
            <DebuggerNonUserCode()> _
            Set(ByVal value As Integer)
                m_f1 = value
            End Set
        End Property
    End Class

I'm not saying this is the best solution but it will work for both VS 2005 and VS 2008. IMHO ideally this attribute when applied to a property would affect both the get and set method.