![]() |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
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; |
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. |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
Delphi-Quellcode:
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:
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;
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; |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
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 :) |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
Delphi-Quellcode:
So solltest Du aus Deinen Endlosschleifen rauskommen ohne Crash, oder?
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; |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
|
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.
|
AW: EAccessViolation führt zu unerwartetem APPCRASH
Stacktrace Schäden hmmm.... ich habe mal etwas gegoogelt und bin bei
![]() Auch ohne dieses Tool gibt es einen kleinen Source ![]() Noch mehr google führte mich hier ![]() |
AW: EAccessViolation führt zu unerwartetem APPCRASH
Zitat:
|
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:
Wenn dort anstatt dem raise E; einfach nur raise; steht, funktioniert die Exceptionbehandlung wie gewohnt.
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; Zu diesem Thema habe ich diese Seiten gefunden: ![]() ![]() 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 20:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz