Time to go memory leak hunting in my service. I’m using AutomatedQA‘s AQTime 4, a really cool tool. I’ve used it’s profiling features in the past, but not the memory leak detection. Since Delphi frees up your allocated memory when you exit the app and/or service, it’s too easy to get sloppy and not free up singleton types of objects. Well, that makes it harder to find actual memory leaks as AQTime is going to flag everything that wasn’t explicitly freed up as a leak. And that will lower the s/n ratio to make the too to hard to use.
So I’m pounding through the code and making sure that everything gets created, gets freed. Great fun, I recommend it for the entire family. I’m starting the service (actually the app version of service, but that’s another posting), then exiting it after it initiatizes. That way I can clear out all of the obvious suspects and then turn my attention to the serious memory leaks.
So I’m in the middle of doing this, when one of the objects that I am now explicitly freeing is now blowing up when I free it. And not in a good way. This object, let’s call him Fredo (not really the name), owns a few accessory objects (call them Phil and Reuben). In Fredo’s destructor, Fredo is destroying Phil & Reuben. In Phil’s destructor, Phil references another object belonging to Fredo and blows up because Fredo has gone fishing and doesn’t exist anymore.
It took a while to figure out what was going on. You see Fredo wasn’t actually fishing, Fredo was still around. Phil was accessing Fredo through a global variable (bad legacy code) because Fredo was a singleton. The variable that reference Fredo had been set to nil, even though Fredo was still in existence.
It took a while, but I figured where and how I had broken Fredo. The code that I had added to destroy Fredo looked like this:
FreeAndNil(Fredo);
The FreeAndNil() procedure was added back around Delphi 3 or so. You pass in an object reference, it free’s that object and sets the reference to nil. Horse and buggy thinking for the managed code set, but useful in non-managed versions of Delphi. The problem was that FreeAndNil doesn’t exactly work that way. Let’s take a quick peek at that code:
procedure FreeAndNil(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := nil;
Temp.Free;
end;
It’s setting the variable to nil before it free’s it. It’s not how it’s documented and it caused my code to fail. There’s nothing wrong with how FreeAndNil is coded, by setting the variable to nil first, other objects can check to see if it still exists and not try to access that object while it’s being destroyed. I just would preferred that the documentation more accurately described the actual functionality.