More on the bug

| 0 Comments
As I mentioned earlier, I found a memory leak in a piece of code and was lamenting the difficulty in providing automatic tests for such a think when you use new and delete directly. I've thought about this some more and I'm now slightly less concerned...

The bug was in the one place that I wasn't using some form of factory to manage dynamic allocation. I was allocating a 'per socket' data structure when a connection was established and supposed to be deleting it when the socket was released; I wasn't. Had I been using a factory to manage the data structure then I would have had a place to instrument and a 'thing' to test for leakage.

I was a bit concerned that my other uses of dynamic allocation were equally at risk, but, in general, the only other dynamic allocation going on is managed by factories; allocators. These are already reasonably easy to test and once I get around to sliding in an interface they'll be mockable. There's still the fact that I'm forcing users of these allocators to use the default C++ heap but that could be fixed by allowing the user to pass in a memory allocation interface... I'm still in two minds about that; it's been on my list of things to do for a long time, a fixed sized memory allocator would probably speed up the buffer and socket allocators; but I haven't needed to tune the performance that finely so haven't bothered with it yet. I've written a performance test or two for the buffer allocator, so I can try various things and know if I'm making things better, by tweaking the memory management, or making things worse by inserting another level of indirection...

Leave a comment