Recent

Author Topic: EAccessViolation: Access violation after last line of program executes  (Read 716 times)

AlanTheBeast

  • Jr. Member
  • **
  • Posts: 73
Small program - about 1500 lines - units included.  This is a terminal program - nothing fancy.

I get the "EAccessViolation: Access violation" at the very end of the run.

I tested this by putting a last "writeln('End.')" in the main program and at the end of the finalization of the units.

The program has been stable for years, but recently (C-19) I've been tidying up. And through that no issues until today when this popped up.

The program does have a lot of linked lists/trees but I've always been careful with such (and if I screw up the crash is much earlier ...).  I don't 'dispose' them (no point in it).  All files are properly closed.  I'm not doing anything cute with local variables that could corrupt the stack.

fpc is 3.0.4 on 10.14.x Mac OS.

Anything I should look at?

Thx.

jamie

  • Hero Member
  • *****
  • Posts: 3528
you said you have other units and code in the finalize and initialize sections.. Have you changed the order of the units in the USES list where as not they are not cycling in the same order ?
The only true wisdom is knowing you know nothing

AlanTheBeast

  • Jr. Member
  • **
  • Posts: 73
No, but I don't think it's relevant.  1 unit is time stuff (very basic, no local globals), the other is a collection of useful procedures and functions that I've been collecting forever ...  and neither uses the other.

Ah, what the heck....  < switching order >   ... no change.

             ... < putting after the sysutils /unix, etc. units >....   nope...

also tried turning off all of the optimizations I had in there .... nope ...

In the end it doesn't matter ... work gets done, files are correctly updated and closed ... just looks messy.


winni

  • Hero Member
  • *****
  • Posts: 1802
Hi!

Just a guess:

There was a similar problem some month ago with Ubuntu and
gtk2. Gtk2 was blamed, but ..... ?

Winni

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 569
There are several reasons for this. One of them - you call destructor twice, i.e. destroy, what should be destroyed automatically. The most nasty reason for that problem - your heap is corrupted. Bad thing about corrupted heap - is that exception happens at place, that is far away from actual problem, and usually requires ASM debugger to catch it and gdb isn't good one (one of the reasons, why I still like Delphi more, than Lazarus). In most cases you need to exclude parts of your code one by one to localize source of problem.

There is another reason for nasty heap corruption in Delphi - forgetting about using ShareMem module.

Does debugger show Break/Continue window? Can you Break and see call stack? Or may be even some place in code in debugger?
« Last Edit: June 02, 2020, 08:53:51 am by Mr.Madguy »
DynamicData 3.0 is released!
Since now development is frozen - only optimization passes will be made at some point.
Lack of multiple inheritance turns it into abomination.

Thaddy

  • Hero Member
  • *****
  • Posts: 10468
did you try and compile with -glh from the command/terminal?
it can be that there is a reference in one unit that is already destroyed in another unit.
That is one example that can cause use after free or a double destroy.
(e.g. a list that owns objects and in another unit a class that is finalized in a finalization section, similar as described above)
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

AlanTheBeast

  • Jr. Member
  • **
  • Posts: 73
It's a classless program.  I know, I know...

PascalDragon

  • Hero Member
  • *****
  • Posts: 2132
  • Compiler Developer
It's a classless program.  I know, I know...

Double frees can occur in procedural programs as well. Just use -glh to see whether you have a double free.

jamie

  • Hero Member
  • *****
  • Posts: 3528
This reminds me of when I dev an app in the WIn95/98 days

worked perfectly there but would randomly fault in W2k..

 It turned out that I had released a Handle to a object in a DLL but then would still use it a few lines down...

 starting with W2k they started to manage the memory differently, reusing memory that was recently returned where as before the oS would always issue new memory from the other end of the pile..

 So basically the Handle information would get overwritten but only would show when used on newer than 98.
The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018