Previously published This article was previously published on megeveski.com when I took some time out to ski. An index of these pages can be found here. Just after we returned from this year’s trip to Megève I was bemoaning the fact that I was back, keen to “run away to the circus” and do another season and wondering how it could be possible to fit all of the interesting ski related things that are going on around “real life”.

Sorry about the lack of technical postings for a while, this last month or so has been rather hard for me. On 13th February I became suspicious that something wasn’t quite right with Michelle, my partner for the last 17 or so years. My suspicions increased and I ended up setting up my laptop in the equipment cupboard as a packet sniffer running Ethereal (now WireShark). I then connected to the laptop via a Remote Desktop Connection and controlled the sniffer from my main PC.

The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com. The latest release is really just a bug fix and compiler compatability release. The code now supports Visual Studio 2005 (as well as VC6, Visual Studio .Net (2002) and Visual Studio 2003). I’ve fixed the memory leak bugs that were present in the ThreadPoolLargePacketEchoServer sample and worked around the iostream leak that’s present in the Visual Studio 2005 version of STL.

Well, it turns out that my initial gut instinct about the leaks that I found in my socket servers when built with VS 2005 was correct. It was an STL thing. The following code reproduces the problem. #include <strstream> #include <sstream> #include <iostream> #include <stdio.h> using std::strstream; using std::ostrstream; using std::stringstream; using std::ostringstream; using std::cout; using std::endl; int main(int argc, char* argv[]) { cout << "Ready - press a key to test strsteam" << endl; getchar(); const size_t loopCount = 100000; size_t i; for (i = 0; i < loopCount; ++i) { strstream buf; } cout << "Ready - press a key to test ostrsteam" << endl; getchar(); for (i = 0; i < loopCount; ++i) { ostrstream buf; } cout << "Ready - press a key to test stringsteam" << endl; getchar(); for (i = 0; i < loopCount; ++i) { stringstream buf; } cout << "Ready - press a key to test ostringsteam" << endl; getchar(); for (i = 0; i < loopCount; ++i) { ostringstream buf; } cout << "Done - press a key" << endl; getchar(); return 0; } The code and projects for VC6 through VS2005 can be downloaded from here.

A while ago I reported that I’d been seeing very strange memory usage patterns in the debug build of the simple echo server when built with Visual Studio 2005 using the standard version of STL that ships with it. The thing that interests me most about this leak is that it seems to be more of a ‘strange allocation strategy’ rather than a leak as I was previously able to get the memory usage to grow to a large amount and then suddenly it dropped back to something reasonable and then started to grow again.

Recently I’ve been getting lots of emails from people who seem to think that my company, JetByte Limited, is currently recruiting. We’re not now and are unlikely to be in the near future, but that doesn’t mean people shouldn’t send speculative emails. In the past I’ve always responded to each of the applicants, explained that we’re not recruiting, and sometimes even made suggestions on how they might improve their approach and/or resume/cv.

Once again I have a list of items flagged for comment in Bloglines but at least this time I have an excuse: “We were on a break!”. First is a link from Brad Wilson to where Bruce Eckel writes about how the “Hyper enthusiasts” of the Java world have moved on to Ruby. Bruce makes some good points. Personally I’d be pretty happy if all persuasuion of “hyper enthusiast” were to vanish overnight, IMHO they just get in the way, distort the picture and encourage bad decisions…

Noel Llopis, over at Games From Within, has written a nice piece about a typical workday at his work place, High Moon Studios. It certainly sounds like a nice way of working. Unfortunately I haven’t been involved in quite that agile a team yet.

I’ve been skiing for the last couple of weeks and now I’m back in London; normal service will resume soon.

It seems that the leak that I found isn’t likely to be the one that my new user of the code is having problems with. They’ve built the code with Visual Studio 2005, made a few (correct) changes to the code to get it to build with the stricter compiler and they find that several of the servers leak; at first it looked like it was just the more complex servers but I’ve just tested the simplest echo server and that leaks in just the same way.