Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi EAccessViolation führt zu unerwartetem APPCRASH (gelöst) (https://www.delphipraxis.net/196469-eaccessviolation-fuehrt-zu-unerwartetem-appcrash-geloest.html)

KodeZwerg 23. Mai 2018 08:23

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von mjustin (Beitrag 1402741)
True ist immer wahr, eine while True do ... Schleife ist somit eine 'Endlosschleife' da die Abbruchbedingung nie False wird

Danke, ich habe Schleifen bis jetzt nie so eingesetzt. Das bedeutet also das selbst bei einem Fehler in der inneren Schleife die "while true do" immer weiter läuft und läuft und läuft... also der Versucht sich permanent zu Connecten, gut zu Wissen!


Ginge es so eventuell?
Delphi-Quellcode:
procedure TProducerLoop.Run;
begin
  while True do
  begin
    if not IsConnected then Connect;

    while IsConnected do
    begin
      try
        ProduceOneMessage;
      except
        on E: Exception do
        begin
          Break; // hier fehler oder auch nicht, schau mal.
        end;
      end;
    end;

    if IsConnected then Disconnect;
  end;
end;

himitsu 23. Mai 2018 08:30

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
k.A. was die ursprüngliche Exception auslöst ... Warum kommt niemand auf die Idee erstmal danach zu sehen?


Nja, wenn irgendwas einen der Stacktraces oder anderen Speicher schrottet, dann kann danach sonstwas kaputt sein und mit etwas Glück auch das ganze Programm abrauchen.

mjustin 23. Mai 2018 08:34

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von KodeZwerg (Beitrag 1402742)
Zitat:

Zitat von mjustin (Beitrag 1402741)
True ist immer wahr, eine while True do ... Schleife ist somit eine 'Endlosschleife' da die Abbruchbedingung nie False wird

Danke, ich habe Schleifen bis jetzt nie so eingesetzt. Das bedeutet also das selbst bei einem Fehler in der inneren Schleife die "while true do" immer weiter läuft und läuft und läuft... also der Versucht sich permanent zu Connecten, gut zu Wissen!


Ginge es so eventuell?
Delphi-Quellcode:
procedure TProducerLoop.Run;
begin
  while True do
  begin
    if not IsConnected then Connect;

    while IsConnected do
    begin
      try
        ProduceOneMessage;
      except
        on E: Exception do
        begin
          Break; // hier fehler oder auch nicht, schau mal.
        end;
      end;
    end;

    if IsConnected then Disconnect;
  end;
end;

Danke, aber das ist nicht erforderlich: die Connect-Methode sieht so aus:

Delphi-Quellcode:
procedure TProducerLoop.Connect;
begin
  while True do
  try
    CreateProducer;
    Logger.Info('Connected %d', [GetCurrentThreadID]);
    IsConnected := True;
    Exit;
  except
    on E: Exception do
    begin
      Sleep(1000);
    end;
  end;
end;
Die ursprüngliche Version - ohne IsConnected - ist aber völlig ausreichend. Den langen Umweg über IsConnected habe ich nur verwendet um das "Break" als Ursache des APPCRASH auszuschliessen. Der Code mit Break benötigt keine weitere Variable für den Abbruch der Schleife, ist funktional identisch, und leichter lesbar:

Delphi-Quellcode:
procedure TProducerLoop.Run;
begin
  while True do
  begin
    Connect;

    while True do
    begin
      try
        ProduceOneMessage;
      except
        on E: Exception do
        begin
          Break;
        end;
      end;
    end;

    Disconnect;
  end;
end;

mjustin 23. Mai 2018 08:44

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von himitsu (Beitrag 1402744)
k.A. was die ursprüngliche Exception auslöst ...

Nja, wenn irgendwas den Stacktrace oder anderen Speicher schrottet, dann kann danach sonstwas kaputt sein und mit etwas Glück auch das ganze Programm abrauchen.

Dem stimme ich 100%ig zu.

Fehler im sonstigen Code, der einen beschädigten Stack verursacht, ist natürlich nicht leicht zu finden.

Sobald ich etwas mehr Zeit habe, schreibe ich eine simple Testanwendung, die nur versucht den Port des Servers zu öffnen. Spanned wird es wenn das dann funktioniert. Ursachen für Stackschäden zu finden ist sicher kein Ponyhof :)

KodeZwerg 23. Mai 2018 08:46

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von mjustin (Beitrag 1402746)
Delphi-Quellcode:
procedure TProducerLoop.Run;
begin
  while True do
  begin
    Connect;

    while True do
    begin
      try
        ProduceOneMessage;
      except
        on E: Exception do
        begin
          Break;
        end;
      end;
    end;

    Disconnect;
  end;
end;

Delphi-Quellcode:
procedure TProducerLoop.Run;
Label MyBreak;
begin
  while True do
  begin
    Connect;

    while True do
    begin
      try
        ProduceOneMessage;
      except
        on E: Exception do
        begin
          Goto MyBreak;
        end;
      end;
    end;
    Disconnect;
    MyBreak:
  end;
end;
So solltest Du aus Deinen Endlosschleifen rauskommen ohne Crash, oder?

mjustin 23. Mai 2018 08:50

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von KodeZwerg (Beitrag 1402748)
So solltest Du aus Deinen Endlosschleifen rauskommen ohne Crash, oder?

Das Problem, das den APPCRASH verursacht, könnte ein Stackschaden sein. Das ist vergleichbar mit einem Hardwaredefekt - einen defekten Speicherchip kann man auch nicht mit Änderungen des Programmcodes reparieren ;)

KodeZwerg 23. Mai 2018 09:02

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Füge doch hier und da ein ShowException(E, ExceptAddr); ein um zu sehen ob woanders ein Fehler übersehen wurde.

KodeZwerg 23. Mai 2018 09:30

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Stacktrace Schäden hmmm.... ich habe mal etwas gegoogelt und bin bei Advanced High-Performance Logging and Tracing for .NET, Java and Delphi gelandet.
Auch ohne dieses Tool gibt es einen kleinen Source Working with Delphi’s new Exception.StackTrace der einem die Basics vermittelt.
Noch mehr google führte mich hier exception-stacktrace in die DP zurück und erklärt wie man es einsetzt.

mjustin 23. Mai 2018 09:37

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Zitat:

Zitat von KodeZwerg (Beitrag 1402756)
Stacktrace Schäden hmmm.... ich habe mal etwas gegoogelt und bin bei Advanced High-Performance Logging and Tracing for .NET, Java and Delphi gelandet.
Auch ohne dieses Tool gibt es einen kleinen Source Working with Delphi’s new Exception.StackTrace der einem die Basics vermittelt.
Noch mehr google führte mich hier exception-stacktrace in die DP zurück und erklärt wie man es einsetzt.

Danke, aber den Stacktrace liefert madExcept (siehe mein erstes Posting, und im verlinkten Artikel von Gurock wird madExcept auch als Tool hierzu genannt) - der Stacktrace sieht auch nicht falsch oder beschädigt aus. Was eventuell beschädigt ist, ist der Stack selbst, oder etwas im Bereich des Delphi Exceptionhandlings.

mjustin 23. Mai 2018 10:29

AW: EAccessViolation führt zu unerwartetem APPCRASH
 
Problem gelöst: es lag an einem raise E; anstatt raise; in einem on E: Exception Handler Block

Delphi-Quellcode:
function TBTMQProducer.InternalSend(const AMessage: IMessage;
  const Destination: IDestination;
  const CompletionListener: ICompletionListener): IMQProducer;
begin
  try
    Producer.Send(Destination, AMessage);
    CompletionListener.OnMessage(AMessage);
  except
    on E: Exception do
    begin
      CompletionListener.OnException(AMessage, E);
      raise E; // ------- <
    end;
  end;
end;
Wenn dort anstatt dem raise E; einfach nur raise; steht, funktioniert die Exceptionbehandlung wie gewohnt.

Zu diesem Thema habe ich diese Seiten gefunden:

https://marc.durdin.net/2012/10/how-...ion-in-delphi/
https://zerolith.com/delphi/on-delph...pt-blocks.html

Fazit: raise; ist korrekt. Mit einem versehentlichen raise E; hat man Stunden oder Tage spannenden Debuggings vor sich ;)


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:24 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz