Lazarus
Programming => General => Topic started by: AlanTheBeast on June 02, 2020, 12:54:32 am
-
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.
-
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 ?
-
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.
-
Hi!
Just a guess:
There was a similar problem some month ago with Ubuntu and
gtk2. Gtk2 was blamed, but ..... ?
Winni
-
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?
-
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)
-
It's a classless program. I know, I know...
-
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.
-
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.