Fehler nach Umstellung auf PostMessage

[yogie]

Hallo Zusammen.

In einer größeren Anwendung habe ich vor einiger Zeit die Übergabe von Strings von einer Unit zu einer anderen Unit von globalen Variablen auf PostMessage umgestellt. Die Daten stammen von einer seriellen Schnittstelle und sind Strings mit ca. 100 Byte Länge. In meinem Hauptfenster werden die Daten empfangen und verarbeitet. Nun bekomme ich bei genügend langer Laufzeit, (d.h. ca. 20000 Übertragungen) die Fehlermeldung "Nicht genug Arbeitsspeicher". Ich habe schon mit diesem Stichwort gesucht und verschiedene Hinweise gefunden.

Hat jemand noch einen Tip wie man weiter vorgehen könnte?
PC ist ein AMD Athlon 64 (2,4 GJz) mit 2 Gbyte Speicher.
Ich verwende Delphi 6.

Hier folgen die beiden relevanten Ausschnitte aus meinem Programm:

Delphi-Quellcode:

procedure TfrmSerial.PostRX_Msg(Msg : shortstring);
var
  pMsgStr : PShortString;
begin
  New(pMsgStr);
  pMsgStr^ := Msg;

  {FormForPostMessage.Handle und die Konstante RX_Msg werden beim 
   Start gesetzt u. ändern sich nicht}
  PostMessage(FormForPostMessage.Handle, RX_Msg, Integer(pMsgStr), 0);
end;

procedure TFrmMain.OnRX_Msg( var M : TMessage);
var
  pMsg : PShortString;
  myStr : string;
begin
  pMsg := Ptr(M.wparam);
  myStr := pMsg^;
  {...Verarbeitung von myStr...}
  Dispose(pMsg);
end;

Eigentlich bin ich der Meinung, das Dispose sollte den mit New angeforderten
Speicher wieder freigeben. Kann es an einer Segmentierung liegen?

[EWeiss]

Dir ist aber schon klar das bei PostMessage nicht gewartet wird?
Du weist also im Normalfall nicht ob das senden des Strings auch erfolgreich war.

Zitat:

Speicher wieder freigeben.

Wenn du nicht warten kannst auf das was du in den Speicher schreibst.
Wie willst du es dann wieder freigeben.
Der Buffer der Seriellen Schnittstelle hat nun mal nur einen begrenzten Platz.

Versuch es mal mit Sendmessage.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1341573)

Zitat:

Speicher wieder freigeben.

Wenn du nicht warten kannst auf das was du in den Speicher schreibst.
Wie willst du es dann wieder freigeben.

Wenn ich das richtig verstanden habe, gibt der Empfänger der Nachricht

Delphi-Quellcode:

OnRX_Msg

den Speicher wieder frei. Es bleibt natürlich noch nachzuweisen, daß auch wirklich alle mit PostMessage verschickten Nachrichten in dem besagten Event ankommen. Allerdings würde ich erwarten, daß das schon vorher aufgefallen wäre.

Ich muss aber gestehen, daß ich mit Delphi 6 nicht mehr so auf dem Laufenden bin.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1341582)

Zitat:

Zitat von EWeiss (Beitrag 1341573)

Zitat:

Speicher wieder freigeben.

Wenn du nicht warten kannst auf das was du in den Speicher schreibst.
Wie willst du es dann wieder freigeben.

Wenn ich das richtig verstanden habe, gibt der Empfänger der Nachricht

Delphi-Quellcode:

OnRX_Msg

den Speicher wieder frei. Es bleibt natürlich noch nachzuweisen, daß auch wirklich alle mit PostMessage verschickten Nachrichten in dem besagten Event ankommen. Allerdings würde ich erwarten, daß das schon vorher aufgefallen wäre.

https://msdn.microsoft.com/de-de/library/bb979347.aspx

Beim arbeiten mit der Seriellen Schnittstelle würde ich meine Daten nicht in einer Warteschlange hinterlegen sondern diese Direkt verarbeiten.
Der Buffer der Schnittstelle hat nur einen Begrenzten Speicher irgendwann läuft dieser über (ist nichts mehr frei)
Zudem reserviert er Speicher versucht diesen zu löschen obwohl er gar nicht weis ob die Daten auch verarbeitet wurden.

Zitat:

Ich muss aber gestehen, daß ich mit Delphi 6 nicht mehr so auf dem Laufenden bin.

Egal welcher Delphi Version man unterliegt ist bei allen das gleiche.

EDIT:
Auf der anderen Seite sehe ich das er seinem Thread ein Property RX_Msg spendiert hat.
Diese sollte nach dem Empfang OnRX_Msg anspringen welche dann den allokierten Speicher wieder freigibt.
Die Frage wäre dann nur noch ob der Pointer dann noch gültig ist oder die Botschaft Schlange nicht schon voll ist.


gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1341584)

Auf der anderen Seite sehe ich das er seinem Thread ein Property RX_Msg spendiert hat.

Einen Thread sehe ich da überhaupt nicht. Anhand der Klassennamen TFrmXXX vermute ich ganz simple TForm-Instanzen. Die serielle Schnittstelle hat mit dem Problem offenbar auch gar nichts zu tun, da hier lediglich ein String über eine Message von einem Form zum anderen transportiert werden soll. Wie auch immer die Daten vom COM-Port empfangen werden, ist hier weder ersichtlich noch relevant.

[yogie]

Erstmal danke für die Antworten.

Die serielle Schnittstelle ist nicht das Problem.
Die läuft gut und ist seit Jahren unverändert. (AsyncPro)
Es sollen tatsächlich nur Daten von einer Form zur anderen
übertragen werden.

Ich habe mal probeweise auf SendMessage umgestellt und werde
das testen.

Bei der Gelegnheit ist mir aber eine andere Stelle im Programm
aufgefallen, die zusammen mit dieser Umstellung geändert wurde.
Ich befürchte ich habe an der falsche Stelle gesucht. Da wird auch
mit PostMessage gearbeitet. Ich habe dort eine rudimentäre Form
des Obsever-Pattern gebaut. Dort scheint mir die Freigabe von
Speicher nicht sauber zu sein. Trotzdem nochmal Danke!

[EWeiss]

Zitat:

Einen Thread sehe ich da überhaupt nicht.

Muss man das?
Sollte Voraussetzung sein wenn man schon mit Postmessage Arbeitet zumindest unter Win32_API.
Wie soll ich sonst in der message Queue die Msg...RX_Msg verarbeiten.

Aber ok er scheint ja die Lösung gefunden zu haben.
Letztendlich kann man an Hand der 3 Zeilen Code auch nur raten.
Warum auch immer Postmessage, einen Vorteil bsp. "Schnelligkeit" sehe ich da keinen.

gruss

[p80286]

Ich könnte mir so etwas vorstellen:

Delphi-Quellcode:

for i:=0 to ganzviel do
  Machwas;
  postmessage();
  application.processmessages;
end;

procedure tform.MyMsg();
begin
 ..
end;

Wenn das vernünftig läuft, lagerst Du den Inhalt der For-Schleife in einen Thread aus.
So als Idee..

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1341608)

Wenn das vernünftig läuft, lagerst Du den Inhalt der For-Schleife in einen Thread aus.

Application.ProcessMessages in einem Thread? Na dann viel Spaß!

[EWeiss]

das hier kann man löschen. Hab da was missverstanden

gruss