1

I am getting this AV message about 3 to 5 seconds after the applications close as expected:

Exception EAccessViolation in module rtl160.bpl at 00073225. Access violation at address 500A3225 in module 'rtl160.bpl'. Read of address 00000004.

These (20) applications are very similar in that they are IBX business applications. About half of them did not cause the AV to occur.

These applications were ported from Delphi-xe and they worked flawlessly for a long time. No changes were made to the projects in the port. Both 32 and 64 bit builds gave the same results.

Is this a bug in some library's finalization section freeing a resource or something?

I am using Delphi-XE2 Update 3.

Would appreciate the help.

Mohammed Nasman
  • 10,992
  • 7
  • 43
  • 68
Experience
  • 98
  • 8
  • Looks like no one is interested in this question. Can anyone who views the question tell me why they won't comment or try to answer it? – Experience Feb 21 '12 at 18:17
  • 2
    It's a really tough question to answer without your application at hand. I can only give a few pointers as to things I've experienced which cause similar. – Disillusioned Jun 06 '12 at 18:35
  • Good article about problems with memory: http://eurekalog.blogspot.com/2010/03/memory-problems-in-delphi-apps-final_30.html – Torbins Jul 07 '12 at 13:38
  • My application uses dynamic packages which are loaded using `LoadPackage` function. Everytime I have had errors like that, I've always resolved the error by rebuilding all projects. – Fabrizio Jun 21 '17 at 12:38

3 Answers3

3

Access Violations are by their nature already very troublesome beasts since they deal with invalid pointers in memory. One that occurs a while after an application shuts down is even worse because that's when your app is in "cleanup" mode. You're could be dealing with something that went wrong much earlier in the application, but is only exposing itself at shutdown.

General Tips:

  • Try to always undo things in the reverse order you did them. E.g.
    • Create A, Create B ... Destroy B, Destroy A
    • Connect to Database, Open Dataset ... Close Dataset, Disconnect from Database
  • Even making sure you've done all the above before shutting down can help tremendously.
  • Any threads that are still running while your application is running can cause problems.
    • Preferably ensure all your child threads are properly terminated before final shutdown.
    • Refer back to Closing datasets above. Depending on what you're doing, some database components will create their own threads.
  • If you're using COM, try ensure ComObj is high up in the initialization sequence (I.e. place it as high as possible in your DPR).
    • Delphi finalizes units in the reverse order that they were initialized.
    • And you don't want ComObj to finalize before other things that are dependent on ComObj have also done so.
  • If you're using interface references, make sure you resolve circular reference issues.
  • Some of these problems can be tricky to find, but you can do the following:
    • Setup a source-code "sandbox" environment (you're going to chuck all your changes as soon as you've found the problem).
    • Figure out the simplest set of steps required to guarantee the error. (Start app and immediately shutdown would be ideal.)
    • Then you're going to comment-out delete wipe out chunks of code between tests and basically follow a divide and conquer approach to:
      • rip out code
      • test
      • if the problem persists, repeat. Else roll-back and rip out a different chunk of code.
    • eventually your code base will be small enough to pinpoint likely problems which can be tackled with targeted testing.
Disillusioned
  • 14,635
  • 3
  • 43
  • 77
3

Try using madExcept / EurekaLog etc. - they give you detailed stack trace on AV. This is not always a panacea, but can point you to the problem.

iPath ツ
  • 2,468
  • 20
  • 31
0

I've had this kind of access violation problem on occasion with old Delphi or C++Builder projects. Today I had it with C++Builder. At the time of the crash, by looking in the Debug -> Call Stack window, I can see that it's happening inside a call to fflush, called by __exit_streams and _exit.

I'm not sure what is causing it, since it's so deep in the Borland library code, but it seems to come and go at random when the code changes. And it seems to be more common with multi-form applications.

This time the error went away when I just added a new button on the main form. A button which is just there, has no event handlers and does not do anything. I think that any random change to the code, classes, variables etc rearranges the memory layout when you relink the application, and that either triggers or untriggers the error.

For now, I just leave the new button on the form, set it to "not visible" so that there's no visible change. As it seems to work, it's good enough solution for me at this time.

PkP
  • 418
  • 3
  • 10