Because of this group i solved a leak / AV in a way that i would not have done before perusing this group.

Because of this group i solved a leak / AV in a way that i would not have done before perusing this group.

The problem, though, comes from me designing an interface and letting some of my TDataModules implement it. I have a mode of instantiating these modules that rely on finalisation handling (where the problem occurred of course)

Ten years ago i would have started to re-factor and re-architect the whole thing to figure out when the problem surfaces and then conclude what not to do.

Yesterday, instead, i went into the CPU view, googled 'delphi cpu view', skipped all entries where the thing is to get rid of the CPU view and read through Brian Longs brilliant page: http://www.blong.com/Conferences/DCon2001/Debugging/Debugging.htm

So - i did not have to re-do anything. After half an hour i realise exactly where to nil something to have everything work 100% cleanly again.

Surely, when i was a kid, i went to ASM courses and did projects but that was such a long time ago and the processor was... hmm... "smaller"? :)

Just saying that this community rocks.

http://www.blong.com/Conferences/DCon2001/Debugging/Debugging.htm

Comments

  1. This community owes a lot to Brian Long too :)

    ReplyDelete
  2. "After half an hour i realise exactly where to nil something..." Not sure if it applies to your situation, but in case it's of value to anyone here, we no longer ever use .Free, preferring FreeAndNil in its place. This assures us that we immediately know (via an AV from de-referencing the nil) if we try to access an object that has already been destroyed.

    ReplyDelete
  3. Tom Field There are times where that practice can bite you hard, such as if your object came from a list that owns it's members. Other than that, I also tend to use FreeAndNil. But now -ARC is here for Linux - and suddenly it becomes a challenge to write cross platform code.

    ReplyDelete
  4. Lars Fosdal Could you explain the OwnsObjects issue you mention?

    ReplyDelete
  5. Tom Field, did you ever have an AV at for example application close? With reference counting and "edge language functions" (although this was true back when too) it can be very tricky to figure out what went wrong.

    The times when you forgot to free something, well that's often a breeze with FastMM and/or madExcept. We go "oh, that one, check that one out".

    At D2009 to XE2 (i think) i had problems with 3rd party libraries. Might have been my misuse or bugs in the libs but oftentimes (and i do not use anything without sources) it can be very tricky to figure out.

    Regarding this time, as i wrote, i misused interfaces. Giving one DataModule an interface to another. At finalisation that went boom and deep down (you know those small call stacks that you can see when you click on the treads). Thing was i had misunderstood the way the reference counter for those works.

    Ergo, i had to nil the interface member after it could be used but before the automatic stuff started and before any finalisation started.

    But this is the thing with interacting with a compiler (ie developing), one learn stuff every day and that's simply great.

    Oh, i have seen on line and even got in messages the /recommendation/ not to worry when a service or app does not close down properly. That way of thinking bites back when you want to update services, they need to close down sharply and snappy regardless if a disc has failed and the database does not answer anymore. So's why i have become so fastidious when i code these last 5 years.

    ReplyDelete
  6. You don't. But if you keep your objects in lists, arrays or containers, and also pass them around - you can quickly end up with them - FreeAndNil or not.

    ReplyDelete

Post a Comment