Unerklärliche Access Violation

[NoName1]

Hallo Delphi-Gemeinde,
ich erhalte miteinemal eine Acess Violation.
Den Rechner habe ich danach neu gestartet und das Programm erneut Compiliert.
Beim Compilieren wird kein Fehler angezeigt. Der Absturz erfolgt, wenn ich das Programm aufrufe.

Was kann kann ich unternehmen, damit alles wieder korrekt ist.

Vielen Dank für Eure Hilfen im Voraus.

[jaenicke]

Passiert der Fehler auch, wenn du das Programm aus Delphi heraus im Debugger startest? Dann solltest du auch sehen, wo der Fehler auftritt.

[Klaus01]

.. du könntest Dir MadExcept installieren, Dein Projekt damit kompilieren und laufen lassen.
MadExcept zeigt Dir in der Regel die Klasse/Methode in welcher der Fehler auftritt.

Grüße
Klaus

[NoName1]

in der Anlage der Bug-Rport von MadExccept.
Bisher konnte ich immer, wenn ein Fehler mit MadExcept angezeigt wurde, diesen auch beheben.
Aber dieses Mal stehe ich auf dem Schlauch. Wo wird der Fehler im Report angezeigt?
Bitte eine Erklärung, wäre mir und evtl. auch anderen Lesern, sicherlich hilfreich.

[Ich habe nochmals 2 Bilder angehängt. Bild-1 die MadExcept-Meldung und Bild-2 die Meldung wenn Break gewählt wird]

[jaenicke]

Die ersten Einträge im Stacktrace zeigen die Fehlerstelle, hier auch ordentlich mit Zeilennummer usw.:

Code:

01e510da +05a Loge.exe     WPViewPDF3             3559   +6 TWPViewPDF.CommandStrEx
01e50bff +043 Loge.exe     WPViewPDF3             3447   +1 TWPViewPDF.CommandGetStr
01e887cb +10f Loge.exe     formFNCPDFBearbeitung   412  +44 TfrmFNCPDFBearbeitung.wpfActionExecute

Der Fehler tritt in Unit WPViewPDF3 in Zeile 3559 auf.

Warum, kannst du am besten im Debugger prüfen. Deshalb habe ich ja gefragt, ob der Fehler dort auch auftritt.

// EDIT:
Landest du dort direkt in der CPU-Ansicht? Wird ein Stacktrace in Delphi angezeigt? Dann kannst du die CPU-Ansicht schließen und dich dort durchklicken.

[Sinspin]

Das sie aus wie ein NullPointer, also wird sicher das Objekt des TWPViewPDF den du da aufrufst, nicht initialisiert sein.

[peterbelow]

[QUOTE=NoName1;1526579]Hallo Delphi-Gemeinde,
ich erhalte miteinemal eine Acess Violation.
Den Rechner habe ich danach neu gestartet und das Programm erneut Compiliert.
Beim Compilieren wird kein Fehler angezeigt. Der Absturz erfolgt, wenn ich das Programm aufrufe.

Was kann kann ich unternehmen, damit alles wieder korrekt ist.

/QUOTE]

Das ist ziemlich eindeutig. Ein "read of address xxx" mit einer sehr niedrigen Adresse ist praktisch immer die Folge eines Fehlers im Kode, wobei eine Methode oder Property eines Objektes über eine Variable aufgerufen wird, die Nil ist anstatt eine valide Objektreferenz zu enthalten.

Ein beliebter Fehler ist hier der falsche Aufruf eines Constructors, d.h.

Delphi-Quellcode:

var 
  aObj: TSomeClass;
begin
  aObj.Create;
  aObj.DoSomething; // Boom!

anstelle von

Delphi-Quellcode:

var 
  aObj: TSomeClass;
begin
  aObj := TSomeClass.Create;
  aObj.DoSomething; // OK

[Kas Ob.]

[QUOTE=peterbelow;1526592]

Zitat:

Zitat von NoName1 (Beitrag 1526579)

Das ist ziemlich eindeutig. Ein "read of address xxx" mit einer sehr niedrigen Adresse ist praktisch immer die Folge eines Fehlers im Kode, wobei eine Methode oder Property eines Objektes über eine Variable aufgerufen wird, die Nil ist anstatt eine valide Objektreferenz zu enthalten.

Ein beliebter Fehler ist hier der falsche Aufruf eines Constructors, d.h.

Delphi-Quellcode:

var 
  aObj: TSomeClass;
begin
  aObj.Create;
  aObj.DoSomething; // Boom!

You are right here, just to point one thing the use of the above function will fail always, the OP said it fails sometimes, so this is not the exact case, also the above will have low access address (closer to 0) only when the stack was clean (zero filled).
My take here, this is a use-after-free case, and likely it was freed using FreeAndNil.

[Kas Ob.]

After thinking, i want to correct my self, the above might not always fail with an exception in fact it could run without any problem,

Delphi-Quellcode:

type
  TMyClass = class
  public
    function DoAdd(A, B: Integer): Integer;
  end;

function TMyClass.DoAdd(A, B: Integer): Integer;
begin
  Result := A + B;
end;

procedure Test1;
var
  C: TMyClass;
begin
  C := TMyClass.Create;
  try
    Writeln(C.DoAdd(5, 7));
  finally
    C.Free;
  end;
end;

procedure Test2;
var
  C: TMyClass;
begin
  //C.Create; not needed at all, with it there will be a memory leak
  Writeln(C.DoAdd(6, 9));
end;

begin
  Test1;
  //Writeln('Soemthing'); // this didn't destroy the stack on my Delphi XE8
  Test2;
  Readln;
end.

The result

Zitat:

12
15

[himitsu]

Im Create ein ShowModal?

Zitat:

Zitat von Kas Ob. (Beitrag 1526612)

Delphi-Quellcode:

  //C.Create; not needed at all, with it there will be a memory leak

Ja und NEIN.

Warum hört eigentlich niemand auf das, was ihm der Compiler an Warnungen zu Recht um die Ohren wirft?
Dieses Vorgehen klappt nur, weil innerhalb der Methode nicht auf das Objekt selbst zugegriffen wird.
Aber eine Mehtode ist gerade dafür da, dass man jenes macht ... ansonsten könnte man auch eine Klassen-Methode verwenden.


Abgesehn davon ist

Delphi-Quellcode:

C.Create;

hier sowieso komplett falscht, weil es

Delphi-Quellcode:

C := TMyClass.Create;

zu sein hat!


Und wenn eine Class-Function, dann nur über deren Klassentyp, anstatt eine uninitialisierte Variable,
denn bei einer Variable wird nötige der Klassen-Typ aus der Objektinstanz geholt, welche es hier aber nicht gibt.

Delphi-Quellcode:

type
  TMyClass = class
  public
    class function DoAdd(A, B: Integer): Integer;
  end;

procedure Test2;
begin
  Writeln(TMyClass.DoAdd(6, 9));
end;

Und ja, natürlich kann man ein

Delphi-Quellcode:

aObj.Create;

nutzen, aber nur, wenn man vorher auch den Instanzspeicher für dieses Objekt instantiiert hat.
Beispiel: siehe TApplication.CreateForm