Rather strange Access Violation

[egsuh]

When I use Heaptrc unit, I have no problem in closing my application. But when I unset it, there are access violation(s) at closing my application. How is this possible? I'm reviewing my codes.

[Thaddy]

Are you using freeandnil a lot?
Then this can be the cause:

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode objfpc}{$endif}{$H+}
2. uses sysutils,classes;
3. {$define HideError}
4. var
5.   List:TStringlist;
6. begin
7.   List := TStringlist.Create;
8.   {$ifdef hideError}
9.   FreeAndNil(List);
10.   FreeAndNil(List);// hides double free, but the error in your code is still there
11.   // the error can subsequently show up elsewhere, like on termination.
12.   {$else showerror}
13.   List.Free;
14.   FreeAndNil(List); // shows the access violation caused by double free.
15.   {$endif}
16. end.

This can happen when you have mixed freeandnil and Tobject.free
Such errors can in rare cases be hidden by heaptrc and are still memory corruptions.
It can also be caused if you included the heaptrc unit manually in the uses clause, which you should never do.
A third option is if you have assigned a cleanup procedure to ExitProc directly instead of using AddExitProc which causes the exitproc list to be corrupted and this may be after heaptrc is done and the system is cleaning up its startup allocations.

On Linux, recuctantly, I would compile for valgrind to find such hard to debug things. Note valgrind needs some expertise to correctly interpret its output. Beginners often draw wrong conclusions from it.(Read are alarmed when nothing is actually wrong)

[egsuh]

@ Thaddy,

I do not use heaptrc manually. Simply from compilation > debugging options (on Windows).

I need to check on FreeAndNil --- I may be trying to FreeAndNil an already-freed object.

Thanks for the comment.

[Martin_fr]

Basically, you have (99.9% likely) a dangling pointer. And you write at some point to memory you already freed, and that may have been allocated by something else. So you overwrite that "something else" with unexpected data.

"You write" => can include any write access by the RTL, triggered by any action of your code. E.g. a "Free" on a dangling object, will cause writes to memory.


As for does only happen with/without heaptrc. When using heaptrc, then extra memory is used (to keep info, for detecting mem leaks). So when you allocate mem, you get mem at different addresses. The address of your dangling pointer changes, and that can (by random chance) change if the overwritten memory is of any importance or not (e.g. it may still be unused, then it may be that nothing happens)...

Mind, that any change in your app (even if not related to the problem) can also have the effect of changing in which order memory is allocated. So if you make a change, the crash may go away. That does not mean the bug has gone.


If you can run your app on Linux (setup a virtual machine if you need) then you can use valgrind. And it will (almost guaranteed) tell you exactly which line(s) access dangling pointers/objects. And also where those were freed (which really helps).

Compile with "debug info for valgrind -gv" => This is important, as it changes the mem manager too / heaptrc must be off for this (don't worry valgrind finds the error, even if it does not crash).

    valgrind --tool=memcheck  ./yourapp

The output can be pasted into menu "view" > "leaks and traces", which allows to navigate to the correct source.

[jamie]

If you are using "memsize" function its most likely your issue because uses its own memory manager and that one reports exactly whereas the one used without heaptrace does not.

 Basically this can lead to problems accessing mem that gets used elsewhere.
 But then again you could be leaking without notice from heaptrc. Heaptrc only monitors unclaimed memory .
Just a thought.