Living in the Tech Avalanche Generation

We left off with IPY.exe crashing and leaving us a dump file. The code that forced the crash:

orders = ctx.Orders.Where(“it.CustomerID > ‘C’“)
for order in Orders:
    print Order.CustomerID

I speculated that something other than member assignment (made by the Entity Framework) to string types in the underlying CLR type of the Python entity was failing and you might remember some proof of concept code was demonstrated to show a variety of ways in specifying types to _clrfields and property decorators.

The Dump File

So decided to re-watch this timely video presentation by Tess Ferrandez and hosted by Scott Hanselman, to see if I could get myself up to speed quick enough to debug the crash dump in VS 2010.

Not that it’s relevant to this topic per`se but did find something odd in locating the dump file and thought it’s worth mentioning here: when the system notifies you of a crash that produces a dump file (on Vista 64 in this case), it went through a process of:

1. Prompting with the message that IPY.exe had indeed crashed
2. Where to find the dump file

After noting the path of the dump file and clearing these two dialogs, I went to retrieve the dump file only to find it was not at all where the dialog said it would be. I ran the process again and watch the target folder for the dump file and it appears that when the second dialog is cleared the dump file will be deleted – so make a copy before that happens!

Anyway back to the problem at hand. Once having secured a copy of the crash dump file I loaded into VS.NET 2010 (very slow with downloading the debug symbols for the first time). Eventually this is what I was presented with:

The information of most note here is the exception information:

“The thread tried to read from or write to a virtual address for which it does not have the appropriate access”

Obviously it’s important to know what was happening on the active thread when debugging for a system that crashed. When prompted to break by visual studio when all the debug symbols have been loaded I received the following message:

An unhandled exception of type ‘System.ExecutionEngineException’ occurred in Unknown Module.

Not very useful so far huh! When I open the parallel call stacks I can see that eight threads were active at the time of the crash and that execution stopped in NT.DLL and in particular on the call listed below.

ntdll.dll!_ZwWaitForSingleObject@12()  + 0×15 bytes

I’m certainly not familiar with debugging dump files but here is what I garnered from the video with Tess. As we look through Call Stack (above) in Visual Studio, we can see that DLR, IronPython and Entity Framework 4.0 functions were called just prior to the failure however it would seem that debug symbols for all three are not currently available on the Symbol Servers from Microsoft. I haven’t yet been able to find them nor been able to locate the source for the special IronPython 2.6 Beta Version for .NET framework 4.0. So we appear to be at impasse, I will continue to see if I can get any deeper into the why and wherefore of the crash and hope to find that one day Plain Old DLR Objects (PODO’s) and Entity Framework can play together in harmony.

Conclusion

It this point in time I would certainly say that using Entity Framework with IronPython will require you build a managed wrapper class(es) that roll up what you want from the entity framework. I showed this to some extent previously with IronRuby in these two posts. Perhaps with a bit of collaborative work the DLR and ADO.NET teams can do a mind meld and move that bit close to making the DLR languages have a more compelling story in this endeavour, however I suppose the question should be asked, is this kind of interop that they have in mind for the dynamic languages?