Version 4.00.21 was a bad build. I screwed up and caused a memory leak. It is as simple as that. I did not push that update out, but still - it was not a good thing and persisted a couple days. Last night, once I was notified of the leak by a concerned user, I made a small patch in v4.00.22 that slowed the memory leak considerably. I intended another update, this is it.
This morning, I took a closer look at the exact code changes in v4.00.21. It was then obvious what I had done. In some unnecessary 'cleanup' I simply made a mistake. I was recreating a global critical section with every new process enumerated, leaking gobs of memory. I have fixed it in v4.00.23. So, if you never went above v4.00.20 you are good. Otherwise, get v4.00.23.
Again, if you are running v4.00.21 or v4.00.22, you should upgrade now. Earlier builds (e.g. 4.00.20) are NOT affected.
I am very sorry for this, and you can bet I am not touching anything now. No future build will be issued without full regression testing. I continue retesting everything in the current build (with no problems seen). I am deeply humbled and embarrassed by this 2.5 day mistake.
What have we done to ensure this never happens again?
I have written new automated QA runtime testing to prevent this from ever happening again. I figure I can't rely on myself, and can't rely on anyone else, but can rely on a simulated environment and automated tester.
Saturday, 27 November 2010
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment