Cornell Box in the evening

What is a “global illumination renderer”?

In short; a global illumination renderer attempts to simulate the way that light behaves in the real world. It bounces rays of light around the scene, noting which surfaces are hit, and how each of them affects the ray. Of course real light travels fast – at about the speed of light, in fact – and our simulated rays can’t match that, so although the resulting effect looks natural, it’s not a very efficient way of getting there. Graphics systems that need to be near real-time (i.e. games), use a variety of short-cuts to try and get the same effect without requiring the same amount of number crunching.

Even this implementation is forced to use a couple of techniques to improve performance, I won’t go into them here, as they’re explained pretty thoroughly on the Minilight site.

Interestingly the algorithm uses a Monte Carlo technique to simulate the random path of the ray through the scene and the same technique is used in finance to model how the price of an asset will change through time.

Translating to F#

Room with sun and light, 800 paths per pixel

Some of the ML constructs caused warnings from the F# compiler as I didn’t use the explicit ML compatibility mode. For instance, the use of the ^ operator to concatenate strings:

warning FS0062: This construct is for ML compatibility. Consider using the '+' operator instead. This may require a type annotation to indicate it acts on strings.

Some other changes included:

• Using dot rather than # notation to access class members
• Using square bracket for array element access (array.[n] rather than array.(n))
• Removing let...and for non-recursive bindings

There was also the opportunity to make use of some of the .NET framework classes, things like System.Drawing.Bitmap to write pixels directly into a bitmap and then save it into a .PNG file. Much easier than trying to find something to read the .PPM file that the original version emits.

Potential improvements

One of the most obvious improvements that could be made is to make use of the parallelism support in F# and .NET. The algorithm itself is easily (if not embarrassingly) parallelisable, given that it iterates over the pixels in the output image, and performs independent operations on each of them. Unfortunately I haven’t had a chance to look at this yet – and the Windows VM I’m using only has a single processor anyway, so on a purely selfish note, I wouldn’t see any immediate performance improvements. It should be as simple as changing the pixel loop to use Parallel.For, or creating an async computation expression.

Something else to note: I err’d on the side of caution when it comes to saving intermediate images, so every iteration it creates and writes the file. This will be doing lots of allocation and strictly unnecessary work, especially for simple scenes.

Given this approach is so completely compute bound it would be interesting to see how moving some of the calculations to a GPU would affect it. It might even be possible to use quotations for some of the inner loops and then generate Nvidia intermediate language (PTX) from them – that’s something I’ve been wanting to do for a while.

I did run the code through the Visual Studio 2010 profiler to get a rough idea of where the time was being spent; it looked like the majority was in the leaf of the calculations where numerical operations where being performed on the vectors, which is consistent with what we’d expect.

Use the source

So, here’s the source. No warranties implied, use at your own risk, your mileage may vary, all errors are mine etc, etc.
minilight_fsharp

What is .NET type equivalence?

Described at a high level here, .NET 4.0 type equivalence essentially gives you a way of indicating that different .NET types represent the same underlying COM type and is most commonly used in COM interop scenarios. One of the reasons for its introduction is to save developers from having to ship large interop DLLs with their software, e.g. the multi-megabyte Microsoft.Office.Interop. Instead the compiler can inline the definition of any types used, and mark them appropriately as representing the original COM types.

The error

We noticed that whenever we built and ran an application that referenced a DLL using .NET 2.0, it worked. Doing the same thing with .NET 4.0 caused a BadImageFormatException.

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. An attempt was made to load a program with an incorrect format.
at X.Main()


Let’s dig!

So, the BadImageFormatException doesn’t actually tell us much. Let’s break out WinDbg and see what we can find. Running the faulting app we can see several C++ exceptions before the CLR exception is thrown:

(178c.790): C++ EH exception - code e06d7363 (first chance)
...
(178c.790): C++ EH exception - code e06d7363 (first chance)
(178c.790): CLR exception - code e0434352 (first chance)

I changed the exception handling settings to stop on C++ exceptions (sxe eh) then ran again to see where things were going wrong. It stopped here:

0:000> kp
ChildEBP RetAddr
0012d15c 79084c0f KERNEL32!RaiseException+0x53
0012d194 793371be MSVCR100_CLR0400!_CxxThrowException+0x48
0012d5e4 79455cae clr!EEFileLoadException::Throw+0x1a8
0012d634 794558d2 clr!CompareTypeTokens+0x200
0012d6b0 791b5c00 clr!IsTypeDefEquivalent+0x102
0012d6d4 791b2ca8 clr!MethodTableBuilder::CheckForTypeEquivalence+0x94
0012d7ac 791b27c9 clr!MethodTableBuilder::BuildMethodTableThrowing+0x60d
0012d9a4 791a4578 clr!ClassLoader::CreateTypeHandleForTypeDefThrowing+0x88e

Interesting. Notice how the call stack contains some .NET 4.0 specific methods relating to the new type equivalence feature. We’re hitting a new code path, which is consistent with the fact that running against a down-level CLR works.

After a bit more toing-and-froing, I discovered that the C++ exception is thrown when clr!MDInternalRO::IsValidToken returns an error. By disassembling the function we can see it’s just looking at various bits in the token value, and it decides that the value passed (0×02000000) isn’t valid. Looking at the output from ildasm that token doesn’t appear anywhere. And if we add a dump of the value, we can see that it indeed doesn’t look like the other tokens:

0:000> bu clr!MDInternalRO::IsValidToken "dd esp+8 L1; g"
...
0012f5a8  02000001
0012f31c  06000001
0012f2c0  02000002
0012f0f4  02000002
0012ebe4  01000001
0012e944  23000001
...
0012d5f4  02000000
(18ec.1ec8): C++ EH exception - code e06d7363 (first chance)

What’s the culprit?

So it looks pretty conclusive; the DLL contains something that the CLR isn’t expecting. But what? It’s time to break out the oldest tool in the troubleshooting box: the binary chop!

Eventually I got the referenced DLL down to only a single simple construct. Can you guess what it is? A global literal value. A real global value, one that isn’t even part of a type. Crazy huh? In IL it looks like this:

.field public static literal valuetype Test.MyEnum LiteralValue = int32(0x00000001)

It’s a literal value of an enumerated type. That’s important: using a value of a simple type (say int32) does not provoke the error.

Now, I wasn’t even sure that this is a valid IL construct, but according to the ECMA IL spec, specifically partition II, section 15, it is:

The CLI also supports global fields, which are fields declared outside of any type definition. Global fields shall be static.

So it looks like we’re not doing anything illegal, backed up by the fact that the .NET 2.0 CLR can make use of it without a problem.

Interestingly, there’s another aspect that influences whether this code path is hit. As mentioned above, type equivalence is intended for use with interop libraries. As such, it only kicks in if your referenced assembly is marked with the PrimaryInteropAssembly attribute, e.g.:


.custom instance void [mscorlib]System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute::.ctor(int32,int32) = ( 01 00 01 00 00 00 00 00 00 00 00 00 )


The Fix?

The issue is currently with Microsoft product support. Let’s see what they come up with; is it too esoteric for a hotfix…?

The Repro

Here’s some code and instructions on how to repro the problem.

1. Build the IL into a DLL using ilasm.
   "c:\WINNT\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" /dll Test.il /output=Test.dll
2. Build the application into a .NET 4.0 EXE that references the DLL
   "c:\winnt\Microsoft.NET\Framework\v4.0.30319\csc.exe" TestConsumer.cs /reference:Test.dll
3. Run the resulting TestConsumer.exe application and you’ll get the exception

Test.il

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly Test
{
.custom instance void [mscorlib]System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute::.ctor(int32,int32) = ( 01 00 01 00 00 00 00 00 00 00 00 00 )
.hash algorithm 0x00008004
.ver 1:0:0:0
}
.module Test.dll
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003
.corflags 0x00000001

.class public auto ansi sealed Test.MyEnum
extends [mscorlib]System.Enum
{
.field public specialname rtspecialname int32 value__
.field public static literal valuetype Test.MyEnum Zero = int32(0x00000000)
.field public static literal valuetype Test.MyEnum One = int32(0x00000001)
}

TestConsumer.cs

class X
{
    static void Main()
    {
        var v = Test.MyEnum.Zero;
    }
}

But what happens if during the lifetime of that stack based COM object, it gets used from .NET? A runtime callable wrapper (RCW) will be created around the object. And this RCW expects to be able to keep the underlying object alive by incrementing its reference count. Of course, the stack-based object will soon go out of scope, and regardless of its reference count the object will be destroyed and the pointer that the RCW contains will no longer be valid. It points into the stack, so when the RCW gets cleaned-up, the CLR will call via this pointer into memory that contains garbage and you’ll get something nasty like an access violation or illegal instruction exception.

It’s fairly easy to reproduce this to see where things go wrong. It can be useful to see where the CLR blows up, and how we can identify this as the cause.

Lets start by creating a simple pseudo-COM object that implements just the bare minimum to be usable:

class MyClass : public IUnknown
{
public:
	MyClass():l(0) {}
	STDMETHOD_(ULONG, AddRef)() { return InterlockedIncrement(&l); }
	STDMETHOD_(ULONG, Release)() { return InterlockedDecrement(&l); }
	STDMETHOD(QueryInterface)(REFIID iid, void ** ppvObject)
	{
		if (iid == IID_IUnknown)
		{
			*ppvObject = this;
			AddRef();
                        return S_OK;
		}
		return E_NOINTERFACE;
	}
private:
	long l;
};

We’ll also need a COM visible .NET object that will use the object. It doesn’t actually need to be COM visible, but that’s the easiest way to access it from C++, in my opinion.

I’ve created the COM object in F#. It’s a trivial class that has a single interface, with a single method that takes the object we pass to it and prints its type. This is enough for the RCW to be created.

open System
open System.Runtime.InteropServices
 
module Module1 =
 
    [<ComVisible(true); InterfaceType(ComInterfaceType.InterfaceIsIUnknown)>]
    type public IConsumer = 
        abstract member UseObject : o:obj -> unit
 
    [<ComVisible(true); ClassInterface(ClassInterfaceType.None)>]
    type public Consumer() =
        interface IConsumer with
            member this.UseObject (o:obj) =
                Console.WriteLine (sprintf "%A" (o.GetType()))

We can compile this into a DLL, then run regasm with the /tlb switch to generate a type library (TLB):

fsc -o:obj\Debug\testStackObjectsFs.dll Module1.fs
regasm /tlb:testStackObjectsFs.tlb testStackObjectsFs.dll

That can be #imported back into our test harness:

#import "testStackObjectsFs.tlb"

Now we’re ready to put together some code that creates an instance of our object on the stack and passes it to our .NET component:

void Foo()
{
	// Create an instance of our "COM object" on the stack
	MyClass obj;
 
	// Create a managed object
	testStackObjectsFs::IConsumerPtr mgd(__uuidof(testStackObjectsFs::Consumer));
 
	// and pass our COM object to it
	mgd->UseObject(_variant_t(&obj));
}
 
int _tmain(int argc, _TCHAR* argv[])
{
	// Initialise the COM runtime, for our purposes it doesn't
	// matter which threading model we use
	CoInitializeEx(NULL, COINIT_MULTITHREADED);
 
	// Call a separate function, to ensure stack-based objects
	// are out-of-scope on return.
	Foo();
 
	// Wait for some input
	_getch();
	return 0;
}

Now, if you run this from within Visual Studio, if you’re vigilant (and you haven’t got your debugger set to stop on access violations), then you’ll notice this in the output window after the return statement executes:

...
The thread 'Win32 Thread' (0x15b0) has exited with code 11001 (0x2af9).
The thread 'Win32 Thread' (0x1110) has exited with code 0 (0x0).
First-chance exception at 0x00850a2b in testStackObjects.exe: 0xC0000005: Access violation reading location 0x00850a2b.
The thread 'DebuggerRCThread::ThreadProcStatic' (0x1534) has exited with code 0 (0x0).
The thread 'RPC Callback Thread' (0x12b8) has exited with code 0 (0x0).
...

Lets ramp up WinDbg, attach to the process (that _getch comes in useful here) and find out what’s going on in a bit more detail.

If we let the app run to the point of failure in WinDbg, we can see that the CLR was in the act of shutting down when it caused the exception:

0:002> kp
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00dae3fc 79f4c1b5 0xe06ff8
00dae450 79f4c26c mscorwks!ReleaseTransitionHelper+0x5f
00dae494 79f4c2d0 mscorwks!SafeReleaseHelper+0x8c
00dae4c8 79faaa01 mscorwks!SafeRelease+0x2f
00dae4fc 79faa7c8 mscorwks!IUnkEntry::Free+0x68
00dae510 79faa91d mscorwks!RCW::ReleaseAllInterfaces+0x18
00dae540 79faa949 mscorwks!RCW::ReleaseAllInterfacesCallBack+0xbd
00dae570 7a0792ac mscorwks!RCW::Cleanup+0x22
00dae57c 7a079714 mscorwks!RCWCleanupList::ReleaseRCWListRaw+0x16
00dae5ac 7a0797df mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx+0xdf
00dae5fc 79fdc140 mscorwks!RCWCleanupList::CleanupAllWrappers+0x77
00dafe90 79fdc7aa mscorwks!RCWCache::ReleaseWrappersWorker+0x103
00dafed8 79fd9f95 mscorwks!ReleaseRCWsInCaches+0x27
00dafee0 79f3c76a mscorwks!InnerCoEEShutDownCOM+0x1e
00daff14 79f92015 mscorwks!WKS::GCHeap::FinalizerThreadStart+0x1fc
00daffb4 7c80b683 mscorwks!Thread::intermediateThreadProc+0x49
00daffec 00000000 kernel32!BaseThreadStart+0x37

Essentially it’s cleaning up the currently unused RCWs – including our malformed one – and as part of doing this, it’s calling Release on the underlying COM object, via the mscorwks!SafeRelease function. SafeRelease wraps the call to potentially (and definitely, in this case) dangerous unmanaged code with various exception handlers, enabling it to silently handle access violations.

If we run the app again, and this time break while it’s waiting for the keypress, before it attempts to clean up the RCWs, then we can examine the wrapper ourselves, using the approach I set out in this post.

List all of the untyped COM object wrappers:

0:002> !dumpheap -type System.__ComObject
 Address       MT     Size
01418628 79306e60       16
total 1 objects
Statistics:
      MT    Count    TotalSize Class Name
79306e60        1           16 System.__ComObject
Total 1 objects

Use the address of the object to obtain its object header:

0:002> dd 1418628-4 L1
01418624 08000002

Use the syncblk identifier in the header to get the syncblk:

0:002> !syncblk 2
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
    2 001e4d9c            0         0 00000000     none    01418628 System.__ComObject
-----------------------------
Total           2
CCW             0
RCW             0
ComClassFactory 0
Free            0

Get the address of the RCW from the sync block:

0:008> dd 001e4d9c+1c L1
001e4db8 001e7dc8
0:008> dd 001e7dc8+c L1
001e7dd4 001de828

And dump out the relevant bits of the RCW, the vtable of the object, at offset 0×88, and the IUnknown pointer, at offset 0×64:

0:008> dds 001de828+88 L1
001de8b0 0041ac78 testStackObjects!MyClass::`vftable'
0:008> dds 001de828+64 L1
001de88c 0012fe7c

We can use !address to do a quick sanity check on the pointer and verify what we know to be the case; it’s stack memory:

0:008> !address 0012fe7c
    00030000 : 00124000 - 0000c000
                    Type     00020000 MEM_PRIVATE
                    Protect  00000004 PAGE_READWRITE
                    State    00001000 MEM_COMMIT
                    Usage    RegionUsageStack
                    Pid.Tid  490.13dc

If we run the app on again to the point that it fails, we can clearly see the address of the object being passed as an argument to mscorwks!IUnkEntry::Free.

So the moral of the story is; don’t pretend some arbitrary piece of stack memory is a real, reference counted COM object. You may be saving the cost of a heap allocation, but even if your app works OK today, it may not tomorrow when someone introduces a piece of .NET code somewhere in your object graph.

Bonus Extra Content

As a bonus tip, here are a couple of WinDbg breakpoints that can be used to dump each RCW as it’s created and destroyed.

bu 79faa974 "dds @ecx L23; g"
bu 79faa538 "dd @esp+20 L1; dds poi(@esp+20)+88 L1; g"


type public MyControl() =
    inherit ItemsControl()
 
    [<defaultValue>]
    static val mutable FooProperty : DependencyProperty
 
    static member OnFooChanged (dob:DependencyObject) args =
        (dob :?> MyControl).Update ()
 
    [<system.ComponentModel.Bindable(true)>]
    member public this.Foo
        with get() : string  = string (base.GetValue(MyControl.FooProperty))
        and  set(r : string) = base.SetValue(MyControl.FooProperty, r)
 
    override this.OnPropertyChanged (args) =
        match args.Property.Name with
        | "Foo" -> this.Update ()
        | _          -> ()
 
    member internal this.Update () =
        System.Diagnostics.Debug.WriteLine (sprintf "Updating %A" (base.GetValue(MyControl.FooProperty)))
 
    static do
        let metadata = PropertyMetadata(null, PropertyChangedCallback (MyControl.OnFooChanged) )
        MyControl.FooProperty <- DependencyProperty.Register("Foo", typeof<string>, typeof<MyControl>, metadata)

Constructor

We don’t have one! Well, that’s not strictly true. There’s no per-instance set-up that we need to do here, so instead we have a default, parameter-less constructor implied by the “empty brackets” syntax in the type declaration. If we wanted to execute some code in the constructor, we could add the following:

    do
        Debug.WriteLine "Constructing."

It’s also possible to add further constructors (perhaps parameterised differently) but when using WPF bear in mind that instances of your class will often be created from a XAML declaration, which generally uses the default constructor and then sets properties as required. Mutable objects: ug.

Inheritance

Our type derives from the WPF ItemsControl class using the inherit keyword. Of course, we’re still subject to the single-inheritance limit of .NET (not a bad thing, if you ask me – no more tortured object hierarchies):

type public MyControl() =
    inherit ItemsControl()

Note that we have to include the empty brackets on the inherited type name, as this will be constructed implicitly when our derived class is constructed. We can access the inherited class from elsewhere in the code using the base keyword.

Static members

Dependency properties are a WPF construct that provide external storage of property values. They allow deep trees of objects to efficiently use lots of properties where they often have the default value, which is commonly the case in WPF. In order to use them with your class you have to do a few things, including creating a static value to hold the property and its metadata. We create a mutable static member for this:

    [<defaultValue>]
    static val mutable FooProperty : DependencyProperty

Why a mutable static value? If you’ve used F# already you might be aware that it’s also possible to declare an immutable static variable and its initial value in one shot with a let:

    static let FooProperty = DependencyProperty.RegisterProperty ("Foo", typeof<string>, typeof<MyControl>)

Unfortunately, this results in your DP being private. Although the CLR property is still accessible, anything that attempts to access the DP directly – for instance, code within the WPF libraries – won’t see it. This means you have to use the mutable style, which is unfortunate.

Static methods

We’ve declared a static member function that is used to receive notifications when our DP is changed (although it’s complete overkill in this example, because we’ve already declared our DP with metadata that tells it to notify us when it changes):

    static member OnFooChanged (dob:DependencyObject) args =
        (dob :?> MyControl).Update ()

As you’d expect, there’s no this parameter on the signature, a static member doesn’t have any implicit object instance to work on. Luckily the arguments to most event functions include the DependencyObject that raised the notification. That means we can downcast dynamically to our expected type (with : ?>) and use it. Bear in mind that this is more like casting than as in C#, as it will throw an InvalidCastException at runtime rather than returning null.

Properties

In order for our dependency property to be easily accessible we can expose it as a plain old CLR property. The implementation of the getter and setter simply defers all of the actual work of storing and retrieving the value to the underlying dependency property.

    member public this.Foo
        with get() : string  = string (base.GetValue(MyControl.FooProperty))
        and  set(r : string) = base.SetValue(MyControl.FooProperty, r)

Notice how we have to cast the obj returned from GetValue into the correct type. This is another example of having to bridge the gap between the dynamically typed WPF property system and F#’s static typing.

Overridden members

As well as providing new member functions and properties, we may need to override existing ones. Member functions marked abstract in the base class can be overridden using the override keyword:

    override this.OnPropertyChanged (args) =
        match args.Property.Name with
        | "Foo" -> this.Update ()
        | _          -> ()

The F# compiler provides the same kind of checking that the C# compiler does, warning you if you inadvertantly hide a base class function by creating an override with the same name but not marking it with override.

Static constructor

As mentioned before, we use the static constructor to initialise our mutable static variables. The syntax is similar to the do syntax of a normal constructor, with the addition of the static keyword:

    static do
        let metadata = PropertyMetadata(null, PropertyChangedCallback (MyControl.OnFooChanged) )
        ...

Static constructors are run once per class, regardless of how many instances of the class you have. WPF relies quite heavily on static, class-based functionality; mostly because a lot of what’s set-up is per-class configuration – it’s not going to change during the lifetime of the application – so you may find yourself doing a fair amount of work in a static constructor.

So, there’s a quick run around some of the object-oriented features of the F# language: classes, inheritance, instance constructors, overridden member functions, static member functions and constructors. You can see how using WPF means you lose some of the benefits of the F# language; notably immutability and static typing. If you’re an experienced functional programmer getting deep into creating WPF or Silverlight custom controls you may find yourself using these OO constructs more than you’d like. Although F# makes it relatively painless in practice, mixing this heavily object oriented style of programming with a functional approach can still be a little hard to stomach at times.

I’m making use of a few F#/.NET idioms to make the process easier. For instance, sequences (.NET’s IEnumerable) are used as the source of uniformly distributed random numbers. Also, to verify that the resulting numbers are actually normally distributed, we can easily use existing WPF/silverlight controls to visualise the values direct from within Visual Studio, in a manner similar to this previous post – but without having to write the plotting code ourselves.

Implementation

So firstly, we create the random number stream:

let rr = System.Random(System.DateTime.Now.Minute)
let rands = seq { while true do yield rr.NextDouble() }

As you can see rands is an infinite sequence. As such, you should be wary of the “eager” functions from the Seq module that attempt to consume the entire sequence at once, they’ll obviously cause a problem here. Also notice that I’ve picked a somewhat dubious seed for the random number generator, as this is only for demonstration purposes.

In order to obtain normally distributed random numbers I’m using the Box-Muller transform. I started off with an implementation transcribed from VBA (from Wilmott et al) – yes, yes, I know – but of course this used mutable references. Not nice. So I reworked it a little to use Seq.pick, which takes items from the sequence while a predicate returns None:

let boxMuller _ =
    let (x,dist) = 
        rands
        |> Seq.pick (fun x ->
            let x = 2.0 * x - 1.0
            let y = 2.0 * ((Seq.take 1 rands) |> Seq.hd) - 1.0
            match (x * x + y * y) with
                | dist when dist < 1.0 -> Some (x,dist)
                | dist -> None
            ) 
    x * Math.Sqrt(-2.0 * Math.Log(dist) / dist)

It’s not particularly efficient as we’re consuming two uniform numbers to generate one normal one – hence the additional Seq.take within the pick. Of course we could change the function to return the 2 generated numbers as an extra element in the tuple.

Next, let’s generate some numbers, and get them in a suitable form to display:

let makeData _ =
    Seq.init 100000 boxMuller
    |> Seq.countBy (fun d -> 
        let d = decimal d
        Math.Round(d, 1))
    |> Seq.sortBy fst

We initialise a sequence with an arbitrary amount of numbers (100000, enough to get a good distribution, hopefully), then use Seq.countBy to do a naive grouping that allows us to see how the numbers are distributed, i.e. counting how many numbers fit in each 0.10 bucket. We then sort the output by bucket.

Visualisation

Now we can display what we’ve got. We can create a simple WPF object-model using imperative code, including the very useful chart control from the WpfToolkit. The chart control enables us to add a series and set our seq<decimal * float> directly as the series ItemsSource, which is the standard way to specify the items for a collection control. If you specify the tuple Item1 and Item2 properties for the bindings, WPF will be able to access the data from each element, and that’s all you need.

    let series = 
        ColumnSeries(
            IndependentValueBinding = Data.Binding("Item1"),
            DependentValueBinding = Data.Binding("Item2"),
            ItemsSource = makeData ())
    let chart = Chart()
    chart.Series.Add series
    Window(
        Name="Plot",
        Title="Normally distributed random numbers",
        Width=900.0,
        Height=700.0,
        Content=chart,
        Visibility=Visibility.Visible)

Here’s the resulting output:
As I’ve mentioned before, this is a fantastically immediate way of doing numerical development in Visual Studio. You can enter all of this code directly into F# interactive within VS, iterate, and quickly see the effect that your changes have. It’s just as interactive as using the graph features in Excel, and the resulting code is much more easily reusable.

XD5RRV3XDNHN

I had a look at the text of the first exception, and from that it was obvious:


Unable to cast COM object of type 'System.__ComObject' to interface type 'IWhatever'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CAD939D0-5E5D-11D7-AA0B-0002B33FE9DX}' failed due to the following error: Bad variable type. (Exception from HRESULT: 0x80020008 (DISP_E_BADVARTYPE)).


The message contains curly brackets around the IID, and they’re being intrepreted as insertion points by a call to String.Format!

Workaround

So that explained why it only happens in debugger runs; as this post helpfully points out the WPF databinding is enabled by default in that case. To workaround it, you can disable logging programmatically or using the App.config file to only display Critical output. So if your app is named foo.exe, create a file foo.exe.config that contains:

<configuration>

  <system.diagnostics>

    <sources>

      <source name="System.Windows.Data" switchName="SourceSwitch"/>

    </sources>

    <switches>

      <add name="SourceSwitch" value="Critical" />

    </switches>

  </system.diagnostics>

</configuration>

Fix…?

Hopefully there’ll be a fix for this at some point soon, as disabling the logging is a pretty large hammer to crack this small nut.

So quite often in our mixed code-base, we find that the .NET garbage collection process doesn’t kick in when we need it to. For instance, when we’ve allocated a lot of memory in the COM code that .NET isn’t aware of. Memory exhaustion has to get pretty bad for the GC to occur at any other time than during a .NET allocation, either the system-wide low-memory event has to be signalled or an OutOfMemoryException needs to be thrown. In both of these cases it’s probably too late to do anything about it.

In this case it’s extremely useful to be able to see what .NET objects are still alive, and what COM objects they’re hanging on to. Unfortunately this isn’t as easy as it might seem.

The COM object itself hides within a weakly-typed System.__ComObject or a strongly-typed managed wrapper, depending on whether rich type information is available. Furthermore, a runtime controller RCW (runtime callable wrapper) is what actually holds a pointer to the object itself, and this structure is internal to mscorwks.dll.

So how can we untangle this and, on finding a __ComObject that happens to still be alive (i.e. is not reachable in the object graph and is therefore eligible for garbage collection) identify which COM object it’s hanging on to.

First of all, let’s see how many __ComObjects are still alive. In this case, it’s only one (phew!):

0:005> !DumpHeap -type __ComObject
 Address       MT     Size
01453b74 79306e60       16
total 1 objects
Statistics:
      MT    Count    TotalSize Class Name
79306e60        1           16 System.__ComObject
Total 1 objects

And you remember the layout of .NET objects in memory, don’t you? Of course you do! The 4 bytes prior to the address displayed (01453b74) are the “object header”. The exact content of the header is apparently undocumented. Let’s see what it contains (at least on a 32-bit platform, your mileage may vary):

0:005> dd 01453b74-4 L1
01453b70  08000002

According to various sources the object header contains 2 fields; a handle and a sync block index. If the object is an RCW, the handle is always 0×08000. You can use the index with SOS’s !syncblk command to de-reference it:

0:005> !syncblk 2
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
    2 001e0fec            0         0 00000000     none    01453b74 System.__ComObject
-----------------------------
Total           3
CCW             0
RCW             1
ComClassFactory 0
Free            0

The sync block itself is an undocumented structure, but after a bit of investigation, it turns out that at offset 0×1c there is a pointer to a further structure that contains the “interop information”:

0:005> dd 001e0fec+1c L1
001e1008  001e9510

And from this, we can obtain a pointer to the RCW itself. We’re almost there!

0:005> dd 001e9510+c L1
001e951c  001e5380

The RCW is a pretty large structure, but for our purposes there are only a couple of interesting fields: the IUnknown pointer at 0×64, and the object’s virtual function table pointer at 0×88. If you use dds you can easily see any symbols associated with these pointers:

0:005> dds 01e5380+64 L1
001e53e4  00ef6c24

0:005> dds 01e5380+88 L1
001e5408  00eb9710 rcwrepro!ATL::CComObject::`vftable'

This is the salient information; we now know exactly what type of COM object we’re dealing with. This is obviously a bit fragile, given that it relies on structures from mscorwks that may well change in newer versions of the runtime (I’ll check on .NET 4 when I get a chance). It’s also a bit of a pain to go through all these steps manually in WinDbg, so I put together a simple extension DLL to do it automatically given the address of the __ComObject. I’ll upload that and blog about it soon.

Calculating option values using F#

The first thing you need is an approximation to the cumulative normal distribution. I used the Abromowitz and Stegun approximation, which should give us enough precision. It’s fairly concise to implement in F#:

let ncdf x =
  let b1 =  0.319381530
  let b2 = -0.356563782
  let b3 =  1.781477937
  let b4 = -1.821255978
  let b5 =  1.330274429
  let p  =  0.2316419
  let c  =  0.39894228
  match x with
  | x when x >= 0.0 ->
    let t = 1.0 / (1.0 + p * x)
    (1.0 - c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1))
  | _ ->
    let t = 1.0 / (1.0 - p * x)
    (c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1))

The CDF should be near 0 for low values, around 0.5 for zero, and near 1 for high values. Let’s check:

> [-5.0; 0.0; 5.0] |> List.map ncdf;;
val it : float list = [2.871049992e-07; 0.500000001; 0.9999997129]

Looks good.

Now let’s put it to use by implementing the option pricing formula for call options:

let call strike spot (rate:float) (now:float) (expiry:float) (vol:float) =
    let exp = expiry-now
    let d1 = Math.Log(spot/strike) + ((rate+(vol*vol)/2.0)*exp)/(vol * Math.Sqrt(exp))
    let d2 = d1 - (vol * (Math.Sqrt(exp)))
    (spot * ncdf d1) - (strike * Math.Pow(Math.E, -rate*exp)*(ncdf d2)), ncdf d1

Notice that the function returns a tuple of (value,delta). Give that the greeks are available analytically we may as well return them at the same time as the value.

We can poke this a bit to check that it’s doing the right thing. A call option that’s way in-the-money (i.e. spot > strike) near to expiry, has a lot of intrinsic value:

> call 10.0 100.0 0.0 0.0 0.1 0.5;;
val it : float * float = (89.26911958, 0.9913821898)

An at-the-money call option should have a delta close to 0.5 at expiry:

> call 10.0 10.0 0.0 0.0 0.1 0.5;;
val it : float * float = (0.6301280626, 0.5315064031)

All seems fine.

So lets see what we can do about visualising these relationships.

Using WPF with F#

You’d be forgiven for thinking that the XAML markup language is the only way to construct user interfaces in WPF. Indeed, if you want to avoid writing code it’s the way to go. But unfortunately it’s not possible to use F# as the code-behind XAML files, so you’re forced to use C#. And it’s also not as dynamic or immediate as it could be; involving the usual write, compile, run iteration. We can do better in F# using scripts and F# interactive (FSI).

The key is to construct the WPF object model imperatively, rather than declaratively with XAML. Yeah, I know this is normally the opposite of what you’d want to do.

For instance, here’s some code to create a Canvas. Note the use of a construction expression to both create the object and set some of it’s properties. This is just syntactic sugar which helps to make the object look slightly less mutable than it actually is:

    let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0)
    c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy))

We can use the WPF canvas panel to enable us to explicitly place points (or rather, Rectangles) on our plot, it uses absolute locations rather than the implied flow layout of the other containers (Grid, StackPanel etc). Putting this together, we can write a function which will take a parent Panel, and a list of (x,y) tuples and create a plot:

let plot (panel:Panel) (pts:(double * double) list) =
    let bgc = new Canvas(Name="Canvas", Width=300.0, Height=300.0)
    let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0)
    c.SetValue(Canvas.LeftProperty, 25.0)
    c.SetValue(Canvas.TopProperty, 25.0)
    c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy))
    let x,y = pts |> List.unzip
    let xmin,xmax = x |> List.min, x |> List.max
    let ymin,ymax = y |> List.min, y |> List.max
    let xscale = c.Width / (xmax-xmin)
    let yscale = c.Height / (ymax-ymin)
    pts
    |> List.map (fun pt ->
        let p = new Rectangle(Width=2.0,Height=2.0)
        p.Stroke <- new SolidColorBrush(Color.FromRgb(0uy,0uy,0uy))
        p.SetValue( Canvas.LeftProperty, (fst pt - xmin) * xscale)
        p.SetValue( Canvas.TopProperty, c.Height - (snd pt - ymin) * yscale)
        p
        )
    |> List.iter (fun rect ->
        ignore <| c.Children.Add rect)
    ignore <| bgc.Children.Add (fst (makeYScale ymin ymax))
    ignore <| bgc.Children.Add (fst (makeXScale xmin xmax))
    ignore <| bgc.Children.Add c
    ignore <| panel.Children.Add bgc
    ()

The function returns nothing (unit in F# parlance) and performs a side-effecting modify of the passed Panel. I’ve omitted the makeXScale and makeYScale functions, as they’re a bit gnarly, and don’t really serve to demonstrate anything in particular.

Now we need to create some data to plot. We can do this in many ways, but one thing I looked at was creating a set of call option values with varying time to expiry. I thought this could use a floating point sequence, but it generated a deprecation warning, so I decided to do it long hand instead. This function returns a list of (time,value) tuples, where time range from rfrom to rto in num steps and value is calculated using the passed function f.

let varyExpiry f num rfrom rto =
    List.init num (fun n ->
        let s = rfrom + ((float n/float num) * (rto-rfrom))
        float s, fst <| f 10.0 10.0 0.05 0.0 s 0.5 )

We can pass the resulting list directly to our plot function, but first we need to create a window to display it in:

let w = new Window(Name="Plot",Width=500.0,Height=500.0)
let wp = new WrapPanel()
w.Content <- wp
w.Visibility <- Visibility.Visible

Executing this code in FSI will display a blank window (probably behind your active window if you're within Visual Studio). Then we can add the plot to the graph:

plot wp (varyExpiry call 100 10.0 100.0)

Voila! Obviously the plot is very, very basic, but it's an interesting experiment, and it does makes it extremely easy to plot functions interactively in almost the same way as you can with applications like Excel and MatLab. Pretty powerful.

Call option values for varying expiries

Call and put option values for varying expiries

There are some other options to more accurately determine whether the method you’re interested in is actually called: run the code, or “almost” run it, by simulating the operation of the CLR. To radically understate; this is quite a lot of work. Yet another option is to statically analyse the original source code. This is generally easier than dynamic evaluation, but there are some serious and well known problems doing it exhaustively, that can result in the complexity eventually converging with that of full dynamic analysis.

So broadly, we have 3 types of approches:

Approach	Implementation	Accuracy
Disassembly	Easy	Superset
Dynamic analysis	Hard	Exact
Static analysis	Medium	Medium

Anyone for a trade-off? Unsurprisingly I decided to look at implementing the third option. Although static analysis is normally performed on the source code itself, it’s actually easier for us to use the generated IL, it certainly requires less gnarly parsing. We can also take some short cuts based on the fact that we’re analysing F# code, more on that later.

We can use F#’s discriminated unions – a type that is constructed from one of many possible options – to describe the universe of IL instructions in a pretty concise way, e.g. (a partial example):

type inst =
    | Nop
    | Break
    | Ldarg_0
    | Ldc_i4 of int32
    | Newobj of meth
and field = FieldInfo
and meth = MethodBase
and typ = Type

This allows us to construct instances of inst by doing something like this in fsi (F# interactive):

> let i = Ldc_i4 2;;
val i : inst

You may have noticed that as well as the instructions that take simple types like int32, we also have ones that accept meth, which is an alias for System.Reflection.MethodBase, the base class for all methods, including constructors, which is what’s used to construct a Newobj.

Now we have this discrimated union defined, we need a way to build instances of it. In the IL byte stream, instructions are stored as opcodes, an unsigned 16bit integer. Firstly we need to get the raw bytes representing the IL. Using Reflection, it’s fairly easy given m of type MethodInfo:

    let body = m.GetMethodBody()
    let ilbytes = body.GetILAsByteArray()
    let ms = new IO.MemoryStream(ilbytes)
    ...

So now we have a stream of bytes, and we can use functions from System.IO to extract information in various sized pieces:

    let getByte _  = (byte (ms.ReadByte()))
    let i2 _ = readInt16 ms
    let i4 _ = readInt32 ms
    ...

As Harry Hill would say; “well, you get the idea with that”. It’s worth noting that these functions have a dummy argument (indicated by the
underscore). This is required because they have a side effect – reading from the stream, changing it’s state – which is not obvious to the compiler, so if we omitted it the function would only be called once. Although adding the dummy arg is required, it does have the unfortunate consequence that we have to pass something (normally unit) which can look a little ugly in the normally terse F# world.

As the ECMA CIL spec describes, IL opcodes consist of either 1 or 2 bytes, in which case the first is always 0xFE. Now we can begin to implement something serious. Given ms of type MemoryStream we can write something that will convert it to instructions:

    match ms.ReadByte() with
    | 0xFE as lb ->
        // Two byte instruction, read further byte
        let hb = getByte()
        let i = ((uint16 lb) <<< 8 ) + (uint16 hb)
        let t =
            match i with
            | 0xfe01us -> Ceq
    | _ as b ->
        let t =
            match b with
            | 0x0 -> Nop
            | 0x1f -> Ldc_i4_s (getByte())
            | 0x20 -> Ldc_i4 (i4())
            | 0x73 -> Newobj (meth())

So we now have a function that will go from a method to a list of opcodes and operands (MethodBase -> inst []). These are essentially the same steps we would perform if we were writing an interpreter for a textual language; taking the source and transforming it into an abstract syntax tree. In that case it’s a tree rather than a list, but the next step is pretty much the same anyway: we pattern match over it. This is the point where we can decide how we want to interpret the instruction stream.

        insts
        |> List.map (fun inst ->
            match inst with
            | Newobj(meth) ->
                printf "NEW: %s.%s\n" meth.DeclaringType.Namespace meth.DeclaringType.Name
            | _ ->
                ()

Here we need to make some compromises based on the problem domain. I’m not trying to create a general purpose static analyser, but one that will work on object code in a certain format – that generated by the F# compiler. As such we make some assumptions and use some knowledge about the internals of the compiler to get the result we’re after. To be specific we’re relying on the fact that the compiler generates types for closures, and we assume that closures will always be called, even though in reality they needn’t be.

So based on this, we can put together something that, given an entry point – a particular method on a type – can recurse through the code, following references to other methods and types via the Newobj, Call, Calli and Callvirt instructions. This will build up a graph of all types referenced directly from our starting point. We also use our intimate knowledge of the purpose of F#’s FastFunc type (from which all functions are derived) and always follow its Invoke method if we find an instance of that type, even if it’s not directly referenced.

There are some major caveats. Anything accessed purely via reflection will not be detected. And polymorphic objects passed in and accessed via interfaces will also be missed. Also, I don’t attempt to do full flow analysis; e.g. following branch instructions etc, as this isn’t a common pattern in fsc-generated IL.

Luckily in the particular cases I’m looking at, these shortcomings don’t have a significant impact. Instead, we end up with a reasonably straight-forward and useful way of determining whether a particular function is called. It’s already been used in anger to determine whether a buggy function was referenced from some release-candidate software.

As a little post-script: rather than writing your own library from the ground-up to do this, there are some “off-the-shelf” solutions that you can try. Notably the recently released CCI, a common compiler infrastructure out of Microsoft Research, that allows you to reverse engineer IL metadata. I haven’t had a chance to have a good look at this yet, but it seems to do what we need for call graph analysis. There’s also an API called AbstractIL – in the absil.dll assembly – that ships with and is used internally by the F# compiler toolset. This looks extremely powerful, but the API is complex and the documentation is poor. Depending on exactly what your motivation is for looking at this stuff, it’s worth checking if these ready-made libraries will do what you need.

So what tools can you use to troubleshoot problems with dynamic IL? In a word: peverify.

What is peverify?
peverify (where PE stands for portable executable, the file format used by Windows executables) takes a .NET assembly and validates the metadata – the type structure – and IL – the instructions, using a combination of rules and static analysis.

As the MSDN pages states it’s intended for use by “compiler writers and script engine developers”, but with a few small modifications to your code you can also use it with Reflection.Emit.

Here’s some example code that uses F# to emit a simple type (deriving from MarshalByRefObject) to wrap another object. The intention is that the wrapper type implements the same interfaces as the underlying object, and delegates calls to it. The key part of the code is where we emit the body of each function.

let wrapObject (obj:obj) =

    let name = "MyAssembly"

    let filename = name + ".dll"

    let ab = AppDomain.CurrentDomain.DefineDynamicAssembly(AssemblyName(name), AssemblyBuilderAccess.RunAndSave)

    let modb = ab.DefineDynamicModule(filename, filename)

    let tb = modb.DefineType("MyType", TypeAttributes.Class, typeof<MarshalByRefObject>)

    let objField : FieldBuilder = tb.DefineField("_underlyingObject", typeof<obj>, FieldAttributes.Public)

    obj.GetType().GetInterfaces() 

    |> Array.iter (fun itf ->

        tb.AddInterfaceImplementation(itf)

        itf.GetMethods()

        |> Array.iter (fun m ->

            let ptypes = m.GetParameters() |> Array.map (fun p -> p.ParameterType)

            let mb = tb.DefineMethod(m.Name, MethodAttributes.Public|||MethodAttributes.Virtual, m.ReturnType, ptypes)

            let il = mb.GetILGenerator()

            // load object reference from field

            il.Emit(OpCodes.Ldarg_0)

            il.Emit(OpCodes.Ldfld, objField)

            // cast it to appropriate type

            il.Emit(OpCodes.Castclass, itf)

            // push all args, verbatim

            m.GetParameters() |> Array.iteri (fun n p -> il.Emit(OpCodes.Ldarg,n+1))

            // call method on underlying objects

            il.Emit(OpCodes.Callvirt, m)

            il.Emit(OpCodes.Ret)

        ))

    let typ = tb.CreateType()

    ab.Save(filename)

    let o = typ.GetConstructor([||]).Invoke([||])

    typ.GetField("_underlyingObject").SetValue(o, obj)

    o

Now, in my first version of the code, I forgot that you need to load “this” onto the stack before loading a field, so the code looked like this:

I used the following code to create an instance of a type implementing IFoo, wrap it and invoke the function:

do

    let o = 

        { new MyInterfaces.IFoo with

            member this.Bar(a) = a + "!" }

    let wrappedObj = wrap o

    wrappedObj.GetType().InvokeMember("Bar", BindingFlags.Instance|||BindingFlags.Public|||BindingFlags.InvokeMethod, null, wrappedObj, [|box "Hello"|])

    ()

As you’d expect the function generated the expected InvalidProgramException:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidProgramException: Common Language Runtime detected an invalid program.
at MyType.Bar(String )
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)


In order to use peverify with your code, the first thing you need to do is save the assembly to disk. This involves making a couple of changes to the code, because normally you’d do everything in memory and avoid the cost of the disk access. First, change Run to RunAndSave in the call to define the assembly:

And ensure you include the filename when you create the module:

Now, you should be able to save the assembly to disk by adding a call after you’re finished building the type:

Be aware that you can’t specify a path in the call to AssemblyBuilder.Save. This is presumably a security restriction; keeping generated binaries within the application’s directory tree and preventing people creating arbitrary binaries all over the file system. If you’re not running from an obvious “top level” application, e.g. you’re using a scripting environment like F# interactive, you may find the location of the file odd; when using FSI from within Visual Studio, the binary is created in “C:Program FilesMicrosoft Visual Studio 9.0Common7IDE”.

Now we can run peverify on the DLL and we get a much richer explanation of the problem:


Microsoft (R) .NET Framework PE Verifier. Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.

[IL]: Error: [c:Program FilesMicrosoft Visual Studio 9.0Common7IDEMyAssembl
y.dll : MyType::Bar][offset 0x00000000] Stack underflow.
1 Error(s) Verifying c:Program FilesMicrosoft Visual Studio 9.0Common7IDEMy
Assembly.dll


From this error message it’s pretty clear that the first thing we’re doing (i.e. the instruction at offset 0) is underflowing the stack; calling an instruction that expects more on the stack than we’ve put there. That should give us a good idea of how to fix the problem.

Another error that I came across was the omission of a cast in the IL:

From which peverify generated the fantastically specific error message:

[IL]: Error: [c:Program FilesMicrosoft Visual Studio 9.0Common7IDEMyAssembl
y.dll : MyType::Bar][offset 0x0000000C][found ref 'System.Object'][expected ref
'MyInterfaces.IFoo'] Unexpected type on the stack.


And of course, once all your emission bugs are fixed, you should get a success report:

All Classes and Methods in c:Program FilesMicrosoft Visual Studio 9.0Common7
IDEMyAssembly.dll Verified.


The only problem with peverify as far as I can see is that there are no compiler style “error codes” to help you identify and resolve the problem. It assumes fairly intimate knowledge of the IL/CLR specification and there may be a bit of effort required to get from the error to the resolution. But one thing’s for sure: it’s definitely easier than trying to do it with just InvalidProgramException.