[Last Call] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1142
  • Last Modified:

Method to track down exceptions memory / object problems

I have written a DLL that handles printing from our application using Gnostice Tools, creating PDFs.  I create a lot of objects on the fly from tables, from streams, there are datamodules and datasets created from information in a database....it is more than slightly complex.  And it works pretty darn well.  However, when I leave the calling application I get first:
The exception unknown software exception (0x0eedfade) occurred in the application at location )x7c81eb33
and then 21 instances of:
The instruction at 0x01ef32df referenced memory at "0x00000000".  The memory could not be read.
After that everything is fine.  When I am testing this within Delphi calling my DLL from a simpler calling program, I get a wonderful clunk/thunk sound as I exit the program, but no error (I assume the clunk is the indicator that it is having a similar issue).
So, the question is, what is a reasonably efficient way to track down what I am doing wrong.  I assume that I have references to objects that are owned, but no longer exist.  I have tried commenting out code, stepping through the close down process, changing all of my .Free to FreeAnNil.
I'd like to solve this without having to look at and retry every line of code.
I need a method to track this down.
I can send code, but there is a lot of it, and really, I would prefer a method that I will be able to use in the future.
As an added piece of information, I do use interfaces on a number of my objects, but I don't think I am freeing any of those (could be wrong).  The problem is there are only 21 errors and I have hundreds of objects so I'm not thinking that is the problem.  But I'm open to suggestion at this point.
1 Solution
Hi there,

I use memproof to find spots where I do things wrong. MemProof gives you the errors and leaks after a run. http://www.automatedqa.com/downloads/memproof/

When there is an exception with "referenced memory at 0x00000000" (the latter 21), it is mostly an object variable that is nil and is accessed by a method or member. Since it is always the same instruction (0x01ef32df) it is probably in a loop where the same object is accessed (or freed) multiple times. The loop is not stopped on the first exception, so the method called does handle exceptions with a try/except without reraising the exception.

The first one has a different address. This is mostly the case when FreeAndNil is not used and you have a dangling pointer. The first exception is probably the cause for the other 21. So you have to look for a method that when it is aborted unexpectedly cause 21 future errors.

You might look for places where you use with/do inside with/do blocks. Name clashes can make you call the wrong object.

You can also try and use find error on the first instruction address. This should point you to the place where it goes wrong. (Use the Delphi menu "Search/Find error")

And a very very clever way of finding the cause for any exception is using madExcept. http://www.madsi.net. I think you can try the software for free. It will give you the complete stack trace (any method called) in any thread of the application on the moment the exception occurs.

One last other options is to alter TObject.Create/TObject.Destroy (or do it at TComponent level) to update a file (inside a critical section) where you update a counter after its class name. Increase when an object is created decrease when one is destroyed. Inspect the file when the exception have occured and open the created file. You will find the classname of objects that are not all destroyted this way. If altering TObject or TComponent is not possible for you can also use this method to instrument any suspect class on its own.

I hope this get you started.

Regards Jacco
dugjohnsonAuthor Commented:
Everything was very useful.  Gave me what I was looking for.  One minor note, it is http://www.madshi.net (there is an h).  Obviously I found it all.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now