Snowflakes and memory leaks

A Christmas debugging story

One of the many problems faced when developing code is what to do when you run out of memory. Text books often describe handling it gracefully. But reality is gnarlier.

Take Windows. It does not cope well with running out of memory. Applications stop drawing. Keyboard input breaks. The mouse stops moving. Windows will attempt to struggle on for a bit, increasingly confused as to what’s going on. But, more often than not, it’ll give up and crash. Or you’ll be forced to reboot.

I first came across this in Windows 3.1 days back in the 90s. Back then I was intrigued how Windows would cope. So I wrote a test app to eat memory - and discovered Windows didn’t cope well. More recently I’ve rediscovered - the hard way - Windows 11 isn’t much better.

My current problem stems from running multiple agents in parallel. Multiple Claudes all building and testing in parallel. Massive terminal scrollback buffers, multiple compilations and a slew of automated tests make it quite easy to consume 40-50GB. All it takes is one bad test that introduces a memory leak and you too can experience the joy of a locked up Windows box.

Things are a little better on WSL; WSL has a out-of-memory checker which kills the WSL process if it runs out of memory. Brutal, but it means Windows survives. Although you lose all your in-flight work.

Introducing MDoomChk

While waiting for my machine to reboot after another Windows crash I had a thought. I could build a little out-of-memory app. It could run in the background monitoring memory and if memory usage hit a threshold it could kill the process using the most memory. Almost always this will be the leaking process (and even if it’s not then it can’t make things worse). Maybe I could avoid reboots?

Soon I had got Claude to build me an app:

By default the app runs in the system tray and tracks memory usage over the past day. I also got it to track CPU and diskspace because, well, why not? It’s just "a prompt away" once you’ve got the infrastructure in place.

Then I decided it’d be nice to track over a longer period - maybe 1 day, 7 days and 31 days. So I marked up a screenshot and asked Claude to add buttons for 1d/7d/31d.

And got this:

The app itself consists of a main process which runs on Windows, plus a helper that runs on WSL and communicates via UDP over localhost. There are also two test apps - one for Windows and one for WSL - that deliberately leak memory to test the main logic. I got Claude to bundle them all together into a single exe - and create a single Windows only build system that cross compiles.

I’m biased but it’s quite an elegant solution.

And so?

AI doesn't just let you build projects faster. It lets you build custom tooling faster. Why settle for a standard hammer when you can have a custom one?

Much of our current tooling is built around human workflows. In the old days, running out of memory was something that happened infrequently. I never used to have ten desktops with thirty tools running in parallel.

But new workflows create new problems. Which need new solutions and tooling.

Fortunately Claude is just as good at building the new tools as it is as building new products. This was a background project built over a weekend.

I’m using Claude to build a tool that prevents Claude from crashing my machine. So I can run more Claudes… I’m sure there’s a lesson there.

And, because it’s Christmas, Claude even added a Christmas mode with appropriately coloured graph lines and a snowflake animation. Merry Christmas!