delphidebuggingcrashaccess-violationeurekalog

Why the debugger won't take me to the line that generated an AV?

I have a program that started to crash on shutdown. The debugger shows:

---------------------------
Debugger Exception Notification
---------------------------
Project Project1.exe raised exception class $C0000005 with message 'access violation at 0x00a69099: read of address 0x70687efe'.

When I click Continue, I see the same error. When I click 'Break' the IDE will open the EMemLeaks.pas unit.
enter image description here

The program is compiled in 'Debug' mode with ALL debugging info included. Map file is set to Details.
enter image description here

Also, I only use FreeAndNil instead of Free in MY code (but not in the 3rd party libraries).

StackTrace (from Delphi IDE):
enter image description here

The crash does not appear if:
- Eureka plugin is disabled or
- Eureka plugin is enabled and the program is running outside the IDE

The crash appears somewhere after "Application.Run". This means that all my clean up code got executed. Right?

Questions:
1. Are the settings above correct? If not, what to change?
2. What does it mean when the debugger cannot put the cursor on the code that generated the problem?
3. Is this an indication that the error is outside my code?

Update (all roads lead to Eureka):

I managed to remove ALL code in my project. This is all that is left:

INTERFACE
USES
  Winapi.Windows, Vcl.Forms,  Vcl.StdCtrls, Vcl.ComCtrls, Vcl.Controls, Vcl.ExtCtrls, System.Classes,
  IdAntiFreeze, IdFTP, IdGlobal, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, IdExplicitTLSClientServerBase, Vcl.Grids;

TYPE
  TfrmDownloader = class(TForm)
    pgCrtl          : TPageControl;
    Splitter        : TSplitter;
    tabMain         : TTabSheet;
    lblTop          : TLabel;
    pnlGrid         : TPanel;
    Panel1: TPanel;
    IdFTP1: TIdFTP;
    btnUpdates: TButton;
    StringGrid1: TStringGrid;
    Panel2: TPanel;
    btnDownStart: TButton;
    RichEdit1: TRichEdit;
  private
  protected
  public
  end;

VAR
   frmDownloader: TfrmDownloader;
IMPLEMENTATION {$R *.dfm}
end.

The project still crashes.

Even more, running a procedure called GenerateCrash will generate EXACTLY the same AV as the one that I get when I shut down the program (and Eureka is active): $C0000005. 

procedure GenerateCrash;   
VAR T: TObject;
begin
 EmptyDummy;
 FreeAndNil(T);
 T.ClassName;
end;

Makes you think. Right? Plus, the EurekaLog support abandoned this issue. Probably they now know about the issue and it will be fixed in some future version (which I won't be able to access). I see that in EACH release they list quite a number of serious bugs. Since their "v7.0 Hot-fix 1" release they introduced 110 features and fixed 271 bugs. Basically with each new featured introduce they also introduced almost 3 bugs! EurekaLog must be ONE OF THE THE MUST BUGGY software products ever!

Solution

  • Debugger will drop you I to the source code if it has debug info available for the source code where the exception is raised. It will have that debug information for your code. But not for RTL/VCL code etc. For a double free then the exception will often occur in RTL code even though the defect is in your code.

    If you enable Debug DCUs then you are more likely to have success. Doing so gives the debugger access to debug info for RTL/VCL code.

    Look at the EurekaLog stack trace though. That should have all you need to explain this.

    Looking at your stack trace the AV is raised in an external DLL, that implements the debug version of FastMM. You won't learn anything by looking at that code. You need to study the stack trace to solve your problem. The answer will not be found where the access violation is raised. Memory corruption errors are frequently of this nature. The error is raised far away from the defect.

    Do be aware that debug FastMM sometimes does raise AV exceptions that it subsequently ignores. These can be very misleading. That could be happening for you. However I have not encountered that at shutdown so I still suspect you have a real defect.

    That said, the defect could well be in EurekaLog or in how you have configured it. If you want my advice I recommend madExcept rather than EurekaLog.