This is a story about leaky abstractions. It’s not a happy story, and I don’t talk about cool things like WPF, AJAX, JSON, POX, or how much I detest the RIAA.
Instead, this is the story of a developer and the Process.Start() method. It’s not exciting, and I don’t mention Silverlight anywhere other than this sentence.
Still, you should listen.
Leaky Abstractions are the technological equivalent of a spring poking through your couch. Until the day that you sat on that rusty, pointy springy-spring, you knew that your couch was comfy. To tell the truth, you really didn’t know, care, or care to know why. Joel Spolsky has his own diatribe on this subject, and it’s worth reading. Of course, he talks about software, and not couch springs, but I’m sure you will still get the point.
Some time ago, my team noticed that a core part of our application would fail to respond, and when we restarted it, it would fail to reclaim its remoting TCP/IP port. Specifically, it listened on port 30123, and whenever we restarted the application, we would receive a System.Net.Sockets.SocketException claiming that the port was already in use. From the command line, a netstat –a verified this information. The netstat output also revealed that the “dead” process had the port still locked. We were mystified, as netstat was reporting a Process ID (PID) that was no longer in the task list.
After much head scratching, we engaged Microsoft Product Support Services. Unfortunately, Microsoft PSS did about as much head scratching as we did. As this problem was only intermittent, our troubleshooting was particularly difficult. Eventually, we were able to repro the issue in our development environments, and Microsoft escalated the issue to their internal debugging teams. We submitted several crashdumps, and discovered some really, really interesting news:
Under certain circumstances, when you launch a process using the Microsoft System.Diagnostics.Process.Start() method, all handles from the parent process are inherited by the child process.
This may not be particularly interesting, but consider the following potential chain of events:
1. Process A starts.
2. Process A opens a TCP port.
3. Process A starts Process B using System.Diagnostics.Process.Start
4. Process A terminates unexpectedly, and does not properly close its TCP port.
5. Process B maintains a copy of the handle to the TCP port.
6. As there is an existing open handle, the Operating System does not close the port when cleaning up dead resources for process A.
It took several user generated crash dumps, but Microsoft PSS finally confirmed that this was the issue.
How does this tie into the concept of Leaky Abstractions? Well, if we examine the Process.Start() method using Reflector, we note the following line of code:
flag = NativeMethods.CreateProcess( null,
If you note the fifth parameter is hardcoded to true, and if you are familiar with the fact that the fifth parameter to CreateProcess is boolean bInheritHandles, I think you’ll understand our handle leak.
I believe that I would be hard-pressed to find a single person (besides the author of Process.Start ) who actually understands that the .NET CreateProcess method defaults the bInheritsHandles bool to true. Nowhere in the Process class documentation is this mentioned, and even our interactions with Microsoft Support failed to pin this issue down until we resorted to crash dump analysis.
What’s the moral of the story? I’m not really sure. I know that I wouldn’t urge anyone to avoid the .NET Process class, but it would be nice if there were mechanisms for finding out this information short of WinDbg and Reflector.
Only 1 bottle of Mountain Dew was harmed during the creation of this article.
Earlier this week, my twelve year old daughter approached me and asked to learn "All that computer stuff that you do." We had chatted previously about my job, but I had taken particular care to not pressure her into learning computers. Such a decision is best left to natural curiousity.
Hanna and I talked about several languages. She had wanted to learn C#, as that is what I spend most of my time with. Instead, I suggested Ruby. I've always wanted to learn the language, and an interpreted environment would make the edit-compile-debug loop a little bit easier.
Ruby has yet to disappoint me as a teaching language. While I haven't found any Ruby books suitable for teaching a pre-teen Ruby programming skills, I have been able to develop simple lesson plans to teach basic concepts. Along the way, I'm also learning the language, which is a big plus for me.
In two days, she has learned console input and output, variables, string comparison, arrays, simple iterators, if / else constructs, and more. It's really been a blast. I'd definitely recommend Ruby as a teaching language.
Next topic: Objects. Wish us luck!
I feel like I just got hit by the dodgeball in elementary school gym class. In a unique game of tag, I'm supposed to tell everyone five things that they didn't know about me. Well, here goes:
1. I spent 6 years in the United States Army as a Military Policeman. I served in quite a few places overseas, incuding time as a NATO peacekeeper in Bosnia.
2. I once assisted the Secret Service in guarding President Clinton. My unenviable task was keeping the press corps from standing in front of a Secret Service SUV packed with every armament imaginable. There was an agent sitting behind the wheel with one foot on the brake, and the other on the gas, with the idea that if there was a threat, he would gun the engine and drive forward in order for the rest of the agents to retrieve heavier firepower. While I'm quite sure that no-one present was overly fond of the press, no-one wanted the headline "Government Agent Creates Speedbump Out of CBS Cameraman. Film at 11." I met the President again shortly after this assignment.
3. Before I was old and slow, I ran track and cross-country in high-school. Back in the day, I used to be able to run a sub-5 minute mile, and once ran a "short" 5k in under 16 minutes. Not world record stuff, mind you, but not bad.
4. I got into Information Technology after leaving the service. I had applied for the Cobb County police department in Georgia, and was waiting for my academy date. While waiting, I applied for an internet tech support job. When my academy date rolled around, I was already a supervisor making almost twice what I would as a police trainee. I stuck with my new career, and here I am eight years later! (I still watch law & order for my cops & robbers 'fix').
5. I would like to try my hand at writing a technical book, but I always feel that it would be a bit presumptuous of me.
Now for the "tag" part - Tag: Yang Cao, Wally McClure, Rob Mensching, DonXML, and Erik Porter.
My Continuous Integration presentation in Dallas, Texas went pretty well. Although I'm not a practiced speaker, it seems that the audience was engaged and interested. I've even been invited to present on the same topic again to another group.
A few loyal readers have complained that the "Occasional Clue" has been a little less occasional than anticipated.
One of the keynote presentations today was on Windows Compute Cluster Solution. Now, I've been working with Windows Clusters in a High Availability environment for some time now, so I've been very interested in what Microsoft's message was going to be in this product space. Microsoft has been getting their lunch handed to them in this area by Linux clusters for a long, long time. While it is currently possible to build High Performance Clusters on Windows without the Compute Cluster Solution, it is certainly not straightforward.
Well, everyone else has been posting about the PDC - I thought that I would have written by now, but I haven't really seen anything that is really exciting. So far, most everything seems to be a refinement of things introduced in PDC 2003.
Oh, Office 12 was mentioned. Since use Office as a glorified Wordpad.exe, that's really not that exciting.
I am currently sitting in the session, "High Performance Computing with Windows Server Compute Cluster Solution." It's a slide-show fest, with very little demo or bits to see. This session is a basic review of of Clustering, and is mostly review if you are familiar with these concepts.
There's actually very little about what microsoft is doing in this space, and more about what high performance clustering actually is. I'm still not impressed. Show me, don't slide-show me.
Sometimes things that everyone just knows aren't always true.
For example, when I look at c# code, I know that local variables are stored on the stack. Or, I thought I knew that.
So, over the last couple of years, I've been what I consider a 'defender' of MSDN documentation. After all, the docs are miles ahead of what they used to be.