Kevin, yes, I use eurekalog with both apps, but it doesn't capture this problem. I guess that means the problem manifests itself only after eurekalog is out of scope. Glad you brought this up though; I can ask the Eurekalog guy what it means when the error isn't trapped.
Double freeing does sound like a possible cause. However, I use class procs within each form to self-create. In other words, the calling code is pretty isolated from the called forms. I.e., it works like this: TMyForm.execute(p1,p2,...); each form sets action:= caFree in the close event handler. In other words, there's really nothing except parameters that could be double-freed. I'll re-review the params for a double-free situation. Unfortunately, last form calls an ocx that doesn't work on my development machine and I can't make the problem happen in the ide. I guess that leaves me with showmessage, and maybe some unusually placed try-except blocks. The uninitialized var sounds interesting, although i'm not quite sure how an access to forbidden memory could be caused by that. This of course is easy to check out, given delphi's compiler warnings. Thanks for your suggestions. From: advanced_delphi@yahoogroups.com [mailto:advanced_del...@yahoogroups.com] On Behalf Of Kevin McCoy Sent: Friday, February 27, 2009 7:13 PM To: advanced_delphi@yahoogroups.com Subject: [advanced_delphi] Re: Memory could not be "read" error when program ends Jeremy, You might try installing EurekaLog. It is pretty good at generating a call stack trace and other debug log information on exceptions like this. It can even email the log to you or send the log + screen shots to a bug tracking web server like Mantis. There is a free, fully functional demo you can use on their web site. You have to pay a nominal fee to get the source, but it is worth it. You may have an uninitialized variable in the common code that only rears its ugly head when it is loaded into a certain position in RAM. It might work fine in one case, because the variable gets loaded with a random, but reasonable value. In the other case, it gets loaded with an unreasonable random value and dies. It could also be that you are double-freeing an object. Are you manually creating a form using Txxxx.Create(Self)? You may need to step through the unit finalization code on the bad application, if you can get it to fail in the IDE. That way you can at least find the place where the crash occurs. Stepping through finalization code is very tedious - done properly anyway ;-) Best regards, Kevin G. McCoy --- In advanced_delphi@yahoogroups.com <mailto:advanced_delphi%40yahoogroups.com> , "Jeremy Grand" <jer...@...> wrote: > > I have a couple of D7.1 apps that use some common code. The common code > causes an error in one app but not the other. The error happens when > the app exits. >
