Exception während RS232 Datenempfang

[akuk]

Zwei PC kommunizeren über RS232. PC1 sendet laufend Daten an PC2.
Eine Exception wird gemeldet (System), trotzdem werden die Daten
weiterhin übermittelt und deren Empfang Quittiert.
Dagegen das Programm-Hauptablauf ist blockiert.

Exception im "System" :
CALL FreeMem, InvalidPointer, "ungültige Zeigeroperation"
siehe Beilage.
Was kann die Ursache sein ? wo soll man suchen ?

[Rollo62]

RS232 kann zu beliebigen Zeiten kommen, müsste also ThreadSicher behandelt werden bevor Du das irgendwo weiterverarbeitest.
Probier das Mal mit TThread.ForceQueue zu entkoppeln.
ce

[zeras]

Ich nehme das hier für RS232 Kommunikation und bin zufrieden damit.

[Medium]

Eine kostenfreie Alternative, die ich seit Jahren immer mal wieder erfolgreich einsetze ist TPAPro. Zuletzt allerdings mit D2007 - ob und wie gut das mit den neuen Delphis spielt kann ich leider nicht sagen. (Wird für mich über kurz oder lang aber sicher auch mal interessant.)


Edit: Das auf Sourceforge scheint veraltet zu sein. Brandaktuelle Versionen habe ich gerade auf GitHub gesehen!

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1459607)

RS232 kann zu beliebigen Zeiten kommen, müsste also ThreadSicher behandelt werden bevor Du das irgendwo weiterverarbeitest.
Probier das Mal mit TThread.ForceQueue zu entkoppeln.
ce

Das kommt drauf an. Ja, viele ComPort-Komponenten haben einen Thread, der die Daten empfängt und vom hardwarepuffer in einen Softwarepuffer kopiert,
aber ein muss ist das nicht.

Aber auch diese komponenten aben meisten keinen unendlich großen Puffer, also muß dessen Programm somit auch die Daten von dort abrufen, damit die Komponente nicht aufhört den Hardwarepuffer zu leeren.


Per se, also ohne Hardwarehandshake, ist die serielle Komunikation meistens ohne Rückkopplung, also niemand bekommt mit, wenn der Andere die "empfangenen" Daten überhaupt verarbeitet, bzw. ob überhaupt jemand zuhört. (es sei denn der andere Antwortet und man wertet das aus)

[Rollo62]

@himitsu
Stimmt, aber mit aktuellen PC's habe ich da eigentlich keine Probleme mehr gehabt,
die sind einfach viel schneller als RS232.
Kommt natürlich auf die Baudrate an.
Beim Debuggen können die Buffer natürlich schon vollaufen im Hintergrund.
Der Fehler kann natürlich trotzdem noch alle möglichen Ursachen haben, war jetzt nur eine Idee.

Ich benutze deswegen einen eigenen Ringbuffer, der threadsicher reinschreibt und auslesen kann,
so das In- und Out völlig entkoppelt sind.
Ich denke mal das einige COM Komponenten das schon drin haben, die Hinweise und Links sind also richtig.
Ich weiss aber nicht was der TE nutzt und wie er das umsetzt.

[akuk]

Hallo
Das rs232 lauft im Thread, darum lauft es weiter auch nach der Exception.
Die Exception passiert also im Hauptablauf. Nur handelt sich um SystemException
,wie finde ich heraus was ist die Ursache.
Das was Debugger zeigt hilft nicht weiter, da ist man schon im System.
Siehe Beilage.

Kan man im RAD Delphi Rio tracen, ich habe es nicht gefunden ?

[Der schöne Günther]

Schau doch mal im Stacktrace kurz darüber,

Delphi-Quellcode:

_UStrClr

und so. Und das läuft in irgendeiner Fensterprozedur eines

Delphi-Quellcode:

TWinControl

. Steckst du irgendwie rohe Bytes in Strings oder sowas?

[akuk]

Hallo schöne Günter
Ich bin ein Anfänger, wo finde ich das UstrCtr resp TWinControl.
ich hab überall gesucht aber nicht gefunden.
Start
Ueberwachte Ausdrcke ?
Parameter ?

ja es passiert in eine Fensteprocedur beim werte abfüllen aber wo habe ich bis
jetzt nicht gefunden.
es sollen Werte die vom Rs232 Thread (byte array) im Fenster Angezeigt werden.
ich hab überall BP gesetzt aber das hat nicht funktioniert.

Besten Dank zum voraus.

[himitsu]

Manchmal bleibt der Debugger auch im falschen Thread stehen, bzw. die eigentliche Fehlerursache kann von wo anders her kommen.
Strg+Alt+T: In der Threadliste kannst du mit Doppelklick umschalten und siehst im Stacktrace dann auch die anderen Threads.

[akuk]

Hallo Himitsu
es sind schon ca.6 Jahre her als wir letztemal miteinander kommuniziert haben.
Ich habe imer noch "Unruhestand" statt "Ruhestand". Nun zu meinem
Problem:
Es wurden insgesamt 4 Threads angezeigt, so wie ich es verstanden habe
alles System Threads.Siehe Beilage.
In meinem Programm gibt es nur ein einzige Threads ,
nämlich für rs232 kommunikation.
Ich habe die ganze Kette durchgesucht von dem Empfang der Daten
(Konkret eine Meldung mit 20 Bytes) bis zu der Prozedur(Anzeige_koordinaten) die in den Fenster hinein schreibt, nichts auffäliges gesehen.
Wenn ich ein BP nach der Prozedur setze komm die Exception noch nicht,
unmitelbar danach geht es in Exception ???

[akuk]

xxxx

[akuk]

Hallo
ich komme dem Problem ein bisschen näher.
Folgende Sequenz löst die Exception aus, aber nur wenn es normal
ablauft.

M4: begin
WriteXY(Image1,22,25,' 6 '); {==testpunkt ============}
//getblk(false);
WriteXY(Image1,22,25,' 7 ');
IstWertAnzeige(Image1); {getblk drin }
WriteXY(Image1,22,25,' 8 ');
F_Neu:=false;
WriteXY(Image1,22,25,' 9');
end;

Wenn ich den 1.BP setze vor IstWertAnzeige und dann weiter mit F9 zu 2.BP
tritt keine Exception auf .
Dagegen wenn ich nur ein BP setze nach IstwertAnzeige kommt die Exception.
d.h. wenn IstwertAnzeige ohne halt durchlauft kommt es zu Exception.
Frage: was hat das mit EInvalidPointer zu tun ? (ungültige Zeiger)

[himitsu]

Tja, viel Spaß beim Suchen von Threadingfehlern.

Vermutung: du hast irgendwo eine Synchronisierung vergessen und die Threads bekämpfen sich.

[akuk]

Hallo Himitsu
Ja das habe ich in der Zwischenzeit auch herausgefunden. Du hast absolut
richtig getippt.
Wenn die Procedur IstwertAnzeige aufgerufen wird während dem im Thread
eine neue IstwertMeldung empfangen wird, dann genau passiert es.

Wie macht man es am einfachsten ?
Nach jede empfangene Meldung eine Freigabe setzen, wenn eine neue Meldung kommt wieder rücksetzen. Oder soll ich zusätzlich noch ein Ack Signal seitens Hauptprogramm generieren ?
Oder gibt es eine bessere Methode ?

[Klaus01]

.. vielleicht hilft es ein
TCriticalSection.Aquire beim Eintritt in die istWertAnzeige setzn
und vor dem Verlassen ein TCriticalSection.Release.

Grüße
Klaus

[Klaus01]

.. ist istWertAnzeige eine Routine Deines Threads oder der Hauptprogramms?

Das Image ist kein Bitmap oder?
Bitmaps sind nicht threadsafe.

Grüße
Klaus

[akuk]

Hallo
Nach dem ich mich durch div. Tutorials durchgekämpft habe versuchte ich
mein Problem mit der Exception zu lösen.
Nun tritt eine andere Exception. Was ich gemacht habe :

In der Unit für RS232 Empfang (OptiNumericCom.Pas) die im Thread läuft
habe ich CriticalSction definiert ab Empfang der Daten bis Empfang beendet

var
.
EmpfangCS : TRTLCriticalSection;
.
.
function TOptiNumericComm.receiveMessage : TMeldung;
.
.
.
EnterCriticalSection(EmpfangCS);
id := recByte; //Empfang von 1.Byte (Meldungstyp) ****** Hier Exception *****

case (id AND $0F)
$01:
// usw
else //Meldung-In (16 Byte) einlesen
begin
SetLength(Result, 17);
Result[0] := id;
for i:=1 to 16
do Result[i] := comport.GetByte;
end;
end; //ende Case
LeaveCriticalSection(EmpfangCS);
======================
Im Hauptprogramm ist keine CriticalSection definiert,is auch nicht nötig,
ich will nur erreichen, dass der Empfang im Thread ohne Unterbruch
durchläuft.

Die Exception tritt auf bereits beim Empfang von 1. Byte. (id := recByte;)
Recbyte befindet sich in eine andere Unit,ist natürlich mit uses deklariert.
Wo ist das Problem ?
Der Datenempfang hat vorher ohne CriticalSection für erste paar Meldungen funktioniert bis Exception auftratt wg. Synchronisation.

[akuk]

Hallo
Ich habe vergessen die CS Initialisieren.
Jetzt läuft es durch,Meldungen werden Empfangen aber
der Empfang wird irgendwie gestört, es kommen wirre Werte über RS232.
Verlangsamt CS den Empfang ?
Und es kommt die alte Exception wieder, wie wenn das CS nicht wäre.
Ich muss es mit dem LA morgen genau anschauen was da passiert.

[Rollo62]

Versuch im Rs232 Empfang nur die Daten z.B. in einem Fifo od. Ringbuffer zu speichern, und dann schnell wieder raus.
Die Verarbeitung dann an einer separaten Stelle Durchführen.

[Sinspin]

Hallo,

beim Empfang solltest Du kein CriticalSection verwenden, denn das kann das Annehmen von Daten blokieren.
Besser ist es wirklich einen ausreichend großen internen Puffer zu verwenden und einen anderen Thread die Verarbeitung machen zu lassen.
Für den Zugriff auf den Puffer musst Du dann sicherstellen das beim auslesen und reinschreiben andere Positionsmarken (Leseposition/Schreibposition) verwendet werden. Ansonsten ist wieder synchonisation nötig, was dann wieder Daten killen könnte.

[akuk]

Hallo Sinspin
das verstehe ich nicht, warum sollen die Daten blockiert sein ,die CriticalSection wird ja auschliesslich durchgelaufen (ich habe nur eine CS).
Hab ich da etwas falsch verstanden ?

In der CS ist der Handshake RTS/CTS und danach der Datenempfang und wieder Rts/cts. Mit dem LA habe ich es angechaut und es scheint richtig zu laufen.

Aber im Hauptprogramm (wo die Daten aus rs232 verarbeitet werden) kommt immer wieder Exception (ungültige Zeigeroperation), habe bis jetzt nicht herausgefunden wo es passiert.

Gibt es eine Möglichkeit im RAD Delphi Rio das man feststellen kann was die Exception ausgelöst hat ? eine Art Tracen ?

[akuk]

Hallo Zusammen
langsam bringt mich das ganze zu Verzweiflung.
Ich habe in allen relevanten Teilen CriticalSection eingefügt um Sicherzustellen das zwischen der RS232 Thread (Daten Empfang) und dem
Hauptprogramm (wo Die Daten analysiert werden und Angezeigt) Die DatenSynchronisation gewährleistet ist.

Ich darf wohl annehmen das der Codeteil der sich innerhalb der CritischeSectionen befindet ausschlisslich durchgelaufen wird.

Ich habe 3 kritischeSektionen(EmpfangCS).
1.) im RS232 Thread,
2.)im Hauptprogramm wo daten aus dem Thread analysiert werden und
3.) angezeigt werden.
Und es kommt kurz nach dem Programmstart immer eine
SystemException (ungültige Zeigeroperation).
Es werden geräde diese Teile mehrmals fehlerlos durchgelaufen, erst
nach mehreren Durchläufen kommt es zu Exception.

Leider kann ich nicht zurückverfolgen was es ausgelöst hat.
Hat jemand Erfahrung damit wie man aus der SystemException zurückverfolgan kann zum Ursprung was es ausgelöst hat.

[Medium]

Doofe Frage am Rande: Nutzt du an all diesen Stellen wirklich die selbe Critical Section; also ein und dieselbe Instanz, oder heißt die einfach nur überall gleich?

Ansonsten fürchte ich, werden wir hier etwas mehr als den bereits gezeigten Code brauchen. Am besten alle Methoden, in denen die CS jetzt verwendet wird, mit möglichst wenigen Kürzungen. Auch die Klassendeklarationen die zu den Methoden gehören wären interessant. Ich muss nämlich gestehen: Ich habe aus den bisherigen Infos null Ahnung was hier wo, wann und mit wem genau passiert.

[akuk]

Hallo Medium
ist keine Doofe Frage, ist ja logisch.
Ja ich habe nur eine CriticalSection (EmpfangCS).Am Anfang war da gar keine.

Das Gesamte Programm ist sehr gross, und die jetztige Version stammt nicht von mir. Ich war 1991 Mit_Entwickler der DOS Version (MS Pascal).
Diese Version war der Ausgangpunkt für die jetztige OOP Version.
Die Firma die OOP Version Entwickelt hat ist leider liquidiert.

Ich teste zuerst nur das enfachste Menue (Manuel),in diesem Menue wird nur Empfangen (Istwert = M04).
Alle andere Meldungen von der CNC werden über rs232 zwahr empfangen
(im Thread) aber vom Hauptprogramm in diesem Menue nicht weiter verarbeitet.

Sende darum nur die 5 Units die meiner Meinung nach in diesem Menue relevant sind, im ganzem sind es 31 Units.
Die Exception tritt dann auf, nach dem das MAN_Menue(TForm11) aufgebaut wird
bevor die Istwerte (siehe NCTBUP12) angezeigt werden. Wenn man schrittweise duch den Programm
geht, braucht es mehrere Durchläufe bis die Exception auftritt.

Vielen Dank zum voraus
Anton

[Rollo62]

Nur mal kurz drübergeschaut, ich würde versuchen das viel kleiner, modularer auseinander zu ziehen.

Hier ein paar Ideen:

in OptiNumericComm:
ich würde immer versuchen die Länge von dem eigentlichen Objekt (hier comport) zu bekommen, nicht von woanders.
Sonst könnte das schnell um die Ohren fliegen wenn Daten nicht vorhanden.

Delphi-Quellcode:

      for i:=1 to 8 do
         Result[i] := comport.GetByte; // was macht denn getByte wenn keine Daten mehr da sind ?

an zig anderen Stellen:
ich würde versuchen Enter - Leave in try - except -finally zu kapseln, um besser debuggen zu können

Delphi-Quellcode:

procedure 
begin
  InitializeCriticalSection(EmpfangCS);
   try
      try
....
      except
        on E : Exception do
        begin
        // wenn hier ein Dummy-Code steht könnte man die Exception debuggen, und damit wissen wo die herkommt
        end;

    finally
        LeaveCriticalSection(EmpfangCS);
    end;
end;

[akuk]

Hallo Rollo62
Ja da hast Du Recht, es is nicht immer konsequent, einmal mit recbyte andermal mit GetByte.Werde ich korrigieren.
Das die CNC Daten richtig sendet darauf kann man sich verlassen,es ist speziel ein Mikrokontroller in der CNC dafür da.

Das andere mit leave in try werde ich versuchen. Das muss ich in allen relevanten Methoden machen, oder ?
Vielen Dank für die Hilfe.
Anton

[Klaus01]

Hallo Anton,

habe mal angefangen das in kleinere Methoden zu packen.
Vielleicht magst Du es Dir mal anschauen.

Grüße
Klaus

[akuk]

Hallo Klaus
Vielen Dank, das ist sehr lieb von Dir.
Ist der Grund für das Aufteilen
das man evt. Exception besser abfangen kann ?
Heute Nachmitag kann ich es schnell probieren.
Gruss
Anton

[Klaus01]

Hallo Anton,

auch das - zusätzlich wird die receiveMessage Funktion lesbarer und übersichtlicher.

Grüße
Klaus

[akuk]

Hallo Klaus
Leider kein Erfolg, es ist sicher nicht im OptiNumericCom, es ist immer die
gleiche System Exception => call FreeMem, ungültige Zeigeroperation.
Gruss
Anton

[akuk]

Hallo Klaus
Da ich vermute den Fehler in Unit F_MAN, habe ich versucht
Try Except dort implementieren. siehe Beilage.
Es gibt aber ein Compilationsfehler der nicht auffinbar ist.
Was mache ich falsch ?
Gruss
Anton

[Klaus01]

Zitat:

Zitat von akuk (Beitrag 1460140)

Hallo Klaus
Da ich vermute den Fehler in Unit F_MAN, habe ich versucht
Try Except dort implementieren. siehe Beilage.
Es gibt aber ein Compilationsfehler der nicht auffinbar ist.
Was mache ich falsch ?
Gruss
Anton

Der Code schaut ok. aus.
Der Compiler mosert über die F_MAN.dfm - hier scheint irgendwo etwas faul zu sein.
16bit unsupported resource.
Vielleciht hilft dieser Thread weiter: https://www.delphipraxis.net/117055-...-resource.html

Noch etwas anderes.
in receiveDataCom wird Speicher für die Messages allokiert.
Die Message wird mit postMessage verschickt und kommt dann
in MainWindowsMessage an.
Wird darin aber nicht freigegeben - zumindest sehe ich es nicht.

Grüße
Klaus

[akuk]

Hallo Klaus
Richtig, bei Start und Compilation wird DFM überschrieben und dann gibt diese
ominöse Fehler. Wenn ich die AVIRA abschalte wird nach dem Start die Kompilation ok.
Ich habe in der Methode ManWindowsMessage den START, M6 und M4
mit try Except ergänzt, die Exception ist immer gleich (call FreeMem, ungültige Zeigeroperation).Siehe Beilage.
So wie ich es verstehe liegt die Ursache weder im OptiNumericCom noch in
F_MAN ,ManWindowMessage oder ?
Ziemlich unwahrscheindlich, aber soll ich vielleicht im F_MAN die FormCreate
testen ?
Werde versuchen nach dem gleiche Rezept nachher die unit F_Mainwindows testen.
Heute habe ich aber genug.
Gruss
Anton

[Klaus01]

Delphi-Quellcode:

procedure TForm11.processM6Message();
begin
  try
    with Status.CNC do begin
      if (ZREFE <> CNC_Status_Alt.ZREFE) or F_Neu
      then begin             {Referenzstatus-Ausgabe}
        violett(Image1);
        case ZREFE of
          0:WriteXY(Image1,27,5,'Referenz nicht angefahren');
          1:WriteXY(Image1,27,5,'Referenz am anfahren     ');
          2:begin
            gruen(Image1);
            WriteXY(Image1,27,5,'Referenz angefahren      ')
          end;
        //otherwise;
        end; {case}
        gruen(Image1);
      end; {then}
      {WriteXY(22,25,' 2        ');}  {==testpunkt ================}
      ByteAusgabe(Image1,CNC_Status_Alt.ZINP1,ZINP1,F_Neu,27, 7); {System-}
      ByteAusgabe(Image1,CNC_Status_Alt.ZINP2,ZINP2,F_Neu,27, 8); {Eingangszustaende}
      ByteAusgabe(Image1,CNC_Status_Alt.ZOUT1,ZOUT1,F_Neu,27,9);   {System-}
      ByteAusgabe(Image1,CNC_Status_Alt.ZOUT2,ZOUT2,F_Neu,27,10); {Ausgangszustaende}
      { -----Achsen Status Ausgabe---------------- }
      for i:= 1 to 8
        do ByteAusgabe(Image1,Achsen_Status_alt[i],Achsen_Status[i],F_Neu,27,13 + i);
      Achsen_Status_alt:= Achsen_Status;
      {----- Achsen Endlage Ausgabe -----------}
      for i:= 1 to 8
        do ByteAusgabe(Image1,Achsen_Endlage_alt[i],Achsen_Endlage[i],F_Neu,37,13 + i);
      Achsen_Endlage_alt:= Achsen_Endlage;
      {---------------------------}
      if FLAG <>  1                   {Endlage inaktiv}
      then begin
        ByteAusgabe(Image1,CNC_Status_Alt.POSA1,POSA1,F_Neu,27,11); {Poser-Zustaende}
        ByteAusgabe(Image1,CNC_Status_Alt.POSA2,POSA2,F_Neu,27,12);
      end; {then}
      WriteXY(Image1,22,25,'  3       ');  {==testpunkt ==============}
      CNC_Status_Alt:=Status.CNC;  { MAN Bildschirm }
      //Taste:=' ';
      //ZeichenLesen(false,Taste);
      WriteXY(Image1,22,25,'   4      ');   {==testpunkt ============}
      {-------- versuch1 --------------------}
      { if (ord(Taste) <> #0) then WriteXY(12,25,Taste);}
      WriteXY(Image1,22,25,'    5     '); {==testpunkt =============}
      {---------------------------------------}
      //case upshift(Taste) of
        //'A':F_obereAchsen:=Not F_obereAchsen       {Anzeigen (toggeln)}
      //otherwise;
      //end; {case}
    end; {with}
  except
    on e:Exception do
      raise Exception.Create(format('Error on processM6Message',[e.Message]));
  end;
end;

procedure TForm11.processM4Message();
begin
  try
    WriteXY(Image1,22,25,'      6   ');   {==testpunkt ============}
    //getblk(false);
    WriteXY(Image1,22,25,'       7  ');   {==testpunkt ============}
    IstWertAnzeige(Image1);   {getblk drin }
    WriteXY(Image1,22,25,'        8 ');   {==testpunkt ============}
    F_Neu:=false;
    WriteXY(Image1,22,25,'         9');   {==testpunkt ===LOOP End=====}
  except
    on e:Exception do
      raise Exception.Create(format(('Error on processM4Message',[e.Message]));
  end;
end;

procedure processStartMessage();
begin
  try
    //InterEnable;{ist nicht mehr aktiv}
    //getblk(false);
    //StatusBild;

    F_obereAchsen:=false;F_obereAchsenAlt:=true; {Ausgabe erzwingen}
    Init_IstWerte(IstWerte_Alt);
    F_Neu:=true;
    //getblk(false);
    IstWertAnzeige(Image1);
    //getblk(false);
    F_MSynch:=false;{Meldungen duerfen zwischendurch eingelesen werden}
  except
    on e:Exception do
      raise Exception.Create(format('Error on processStartMessage',[e.Message]));
  end;
end;

procedure TForm11.ManWindowMessage( var Message : TMessage );
var MessageData : PDataMessage;
    GetMessageData : PDataMessage;
    NCSatz      :T_NCSatz;
    Parity      :char;
    Data      :stringx;
begin
  // InitializeCriticalSection(EmpfangCS);  das würde ich in FormCreate verlegen.
  EnterCriticalSection(EmpfangCS);
  try
    case Message.WParam of
      START:  processStartMessage;

      M6:     processM6Message;

      M4:     processM4Message;
    end;
  finally
    LeaveCriticalSection(EmpfangCS);
  end;

.. die Case-Anweisungen in eigene Methoden gepackt.
Die Event-Handling Methode gewinnt dadurch an Übersichtlichkeit.

.. und vielleicht bei der Verschickung von Nachrichten von postMessage auf sendMessage umstellen.
Hintergrund: https://www.delphipraxis.net/122733-...ndmessage.html

Grüße
Klaus

[Medium]

Zitat:

Zitat von Klaus01 (Beitrag 1460179)

und vielleicht bei der Verschickung von Nachrichten von postMessage auf sendMessage umstellen.

Nachrichten zwischen Threads nur mit PostMessage()!

[Klaus01]

Zitat:

Zitat von Medium (Beitrag 1460181)

Zitat:

Zitat von Klaus01 (Beitrag 1460179)

und vielleicht bei der Verschickung von Nachrichten von postMessage auf sendMessage umstellen.

Nachrichten zwischen Threads nur mit PostMessage()!

Was ist der Grund dafür?
Gilt das auch für Thread -> MainThread?

Ok. - habe es gefunden - SendMessage wartet bis die Nachricht angenommen wurde, bis dahin stoppt der Thread seine Arbeit.

Grüße
Klaus

[akuk]

Hallo Zusammen
"Ok. - habe es gefunden - SendMessage wartet bis die Nachricht angenommen wurde, bis dahin stoppt der Thread seine Arbeit."

Der rs232 Thread darf unter keinen Umständen angehalten werden, sonst
verpasst man weitere Meldungen von der CNC, resp. Meldungsempfang wird
unterbrochen was ja noch schlimmer wird.

Habe ich es richtig verstanden,es kommt nur PostMessage in Frage?

Es ist immer noch nicht klar von wo die System-Exception her kommt, oder ?

Gruss
Anton

[Klaus01]

Hallo Anton,

nein - ist mir nicht klar wo die Exception ausgelöst wird.
System Exception => call FreeMem, ungültige Zeigeroperation

Deutet darauf hin, dass "ein Datensatz/record" schon freigegeben wurde
und jetzt versucht wurde ihn nochmals freizugeben.

In der receiveCom Methode werden pro RS232 Nachricht in Datensatz erzeugt "new()".
Wo werden diese wieder freigegeben -> dispose()?

Grüße
Klaus

[Medium]

Zitat:

Zitat von Klaus01 (Beitrag 1460185)

Ok. - habe es gefunden - SendMessage wartet bis die Nachricht angenommen wurde, bis dahin stoppt der Thread seine Arbeit.

Das eigentlich schlimme hierbei ist aber nicht das Anhalten selbst, sondern warum der Aufrufer anhält: Bei SendMessage wird die WndProc des Empfängers direkt wie ein regulärer Methoden-Aufruf aufgerufen. Das hat zur Folge, dass diese nun im Kontext des aufrufenden Threads ausgeführt wird, und somit auch alle Ereignis-Handler die aufgrund der Message dann aufgerufen werden. Insbesondere bei Delphi's Haupt-Thread heißt das, dass dort sehr wahrscheinlich auch VCL-Aufrufe stattfinden, aber auch vieles andere was nicht thread-safe (oder schlimmer noch: context sensitive) ist. Die Blockade des Threads ist eigentlich schon fast der mildeste Effekt.

Es mögen sicher einige daher kommen und behaupten, dass sie damit noch nie Probleme hatten, und das in ihren Programmen immer 100% funktioniert hat. Mag sein! Aber das wäre dann ein klarer Fall von Glück gehabt. Ich selbst bin in dieser Sache, als ich meine ersten Gehversuche mit Threads gemacht habe, mehrfach fies auf die Nase gefallen. Zum Glück - so bin ich recht schnell auf diese Thematik gestoßen und hab's von früh an "richtig" machen können. Definitiv eine subtile Sache, die man einfach wissen muss. (Also nicht "muss" muss, sondern es ist bloß nicht intuitiv dass das so ist :) )