AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi PostMessage: Objekte "verschicken" führt zu Access Violation
Thema durchsuchen
Ansicht
Themen-Optionen

PostMessage: Objekte "verschicken" führt zu Access Violation

Ein Thema von s.h.a.r.k · begonnen am 4. Mär 2011 · letzter Beitrag vom 4. Mär 2011
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#1

PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 02:41
Gute Nacht,

ich steh gerade glaub übelst auf dem Schlauch und hoffe, dass ihr mir helfen könnt. Hintergrund: Ich schreibe gerade eine Logging-Klases in der eine Add-Methode ein Objekt erzeugt, also die Message die geloggt werden soll. Via PostMessage schicke ich dann die Referenz auf das Objekt an verschiedene Module. Hier mal der Auszug, der das Erzeugen und Versenden beinhaltet:
Delphi-Quellcode:
procedure TApLog.Add(const AMessage: String; const ACategory: TApLogCategory);
var
  OriginalMsg : TApLogMessage;
begin
  OriginalMsg := TApLogMessage.Create(AMessage, ACategory);
  try
    SendToModules(OriginalMsg);
  finally
    OriginalMsg.Free();
  end;
end;

procedure TApLog.SendToModules(Source: TApLogMessage);
var
  i : Integer;
  ClonedMsg : TApLogMessage;
begin
  // Clone and send message to each module
  for i := 0 to FModuleHandles.Count - 1 do
  begin
    ClonedMsg := TApLogMessage.Create(Source);
    PostMessage(FModuleHandles[i], APM_LOG_MESSAGE, Integer(@ClonedMsg), 0);
  end;
end;
So, nun zum Empfängercode -- hier wird der Pointer dereferenziert (also das "Objekt") in eine Queue gespeichert:
Delphi-Quellcode:
procedure TApLogCustomModule.APMRecieveMessage(var Msg: TMessage);
var
  p : ^TApLogMessage;
begin
  try
    p := Pointer(Msg.WParam);
    FMessageQueue.Enqueue(p^);
    while (Cardinal(FMessageQueue.Count) > FMaxBufferElements) do
      FMessageQueue.Dequeue().Free();
  finally
    Msg.Result := 1;
  end;
end;
Der Pointer wird korrekt verschickt und stellt somit nicht das Problem dar. Allerdings erhalte ich eine Zugriffsverletztung, wenn die Enqueue()-Methode aufgerufen wird. Zudem habe ich mit der Überwachung festgestellt, dass sicher hinter p kein TApLogMessage verbirgt, also als wäre es freigegeben worden. Aber das geschieht nirgends! Ich habe das mind. 5 mal geprüft.

Nun drängt sich mir die Frage auf: Wird Speicher vom Delphi-Speichermanager überschrieben, wenn keine Referenz mehr darauf exisitert? So weit ich weiß, ist das aber doch nicht der Fall?! Anders kann ich mir aber nicht erklären, warum ich sonst die Zugriffsverletztung erhalte.

PS: Nein, ich werde und will kein SendMessage verwenden.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von Björn Ole
Björn Ole

Registriert seit: 11. Jul 2008
166 Beiträge
 
Delphi XE Professional
 
#2

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 04:50
Was das Senden angeht: keinen Pointer darauf (doppelt gemoppelt), sondern das Objekt selbst: PostMessage(FModuleHandles[i], APM_LOG_MESSAGE, Integer(ClonedMsg), 0);
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.276 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 08:00
Hallo,

ausserdem würde ich nicht wParam, sondern lParam benutzen.
Oder ist Word seit neuestem 32Bit gross ?


Heiko
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#4

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 08:03
Was sind das für Module? Befinden sie sich in einem eigenen Prozess?
Dann hat der Empfänger evtl. einfach keinen Zugriff auf den Speicherraum des Senders.
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.477 Beiträge
 
Delphi 12 Athens
 
#5

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 09:33
Und natürlich auch den Empfang des Objektes anpassen:
Delphi-Quellcode:
procedure TApLogCustomModule.APMRecieveMessage(var Msg: TMessage);
var
  p : TApLogMessage;
begin
  try
    p := Pointer(Msg.WParam);
    FMessageQueue.Enqueue(p);
    while (Cardinal(FMessageQueue.Count) > FMaxBufferElements) do
      FMessageQueue.Dequeue().Free();
  finally
    Msg.Result := 1;
  end;
end;
PS.
WParam und LParam sind beide jeweils 32Bit.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#6

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 09:55
Um den Grund nochmal zu nennen:
Du versendest einen Zeiger auf die Variable und nach Beenden der Prozedur ist diese Variable nicht mehr vorhanden.

PS: Ein Objektzeiger ist, wie der Name vermuten läßt, intern auch "nur" ein Zeiger, weswegen man ihn auch direkt casten kann.
$2B or not $2B
  Mit Zitat antworten Zitat
Benutzerbild von rollstuhlfahrer
rollstuhlfahrer

Registriert seit: 1. Aug 2007
Ort: Ludwigshafen am Rhein
1.529 Beiträge
 
Delphi 7 Professional
 
#7

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 12:24
Versuche es mal mit SendMessage. Da damit die Ausführung direkt durchgeführt wird, sind die lokalen Variablen der aufrufenden Funktion noch vorhanden. Bei PostMessage sind diese meist schon wieder aufgeräumt, da du .Free aufrufst, bevor die Nachricht überhaupt ankam.

Bernhard
Bernhard
Iliacos intra muros peccatur et extra!
  Mit Zitat antworten Zitat
Benutzerbild von jfheins
jfheins

Registriert seit: 10. Jun 2004
Ort: Garching (TUM)
4.579 Beiträge
 
#8

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 12:27

Delphi-Quellcode:
...
  finally
    OriginalMsg.Free();...
... also als wäre es freigegeben worden. Aber das geschieht nirgends! Ich habe das mind. 5 mal geprüft.
*rofl* An der Stelle musste ich echt lachen

Mit records würde das funktionieren, ansonsten darfst du das Objekt nicht freigaben wenn du es noch verwenden willst! Bist du nen GC gewohnt?

@himi: Wenn man ein Objekt erzeugt, sollte das aber doch eigentlich auf dem Heap geschehen, also sollte das eigentliche Objekt (sofern man es nicht freigibt) doch auch nach der Funktion vorhanden sein, oder?

@hoika: Beide Parameter sind 32 bit groß. Trotz des Namens

Geändert von jfheins ( 4. Mär 2011 um 12:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#9

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 12:37
@himi: Wenn man ein Objekt erzeugt, sollte das aber doch eigentlich auf dem Heap geschehen, also sollte das eigentliche Objekt (sofern man es nicht freigibt) doch auch nach der Funktion vorhanden sein, oder?
Das Objekt ja, aber die lokale Variable, worin der Objektzeiger abgelegt wurde und worauf der übergebene Zeiger zeigt, die wird natürlich spätestens zum Prozedurende weg sein.
$2B or not $2B
  Mit Zitat antworten Zitat
Benutzerbild von Bummi
Bummi

Registriert seit: 15. Jun 2010
Ort: Augsburg Bayern Süddeutschland
3.470 Beiträge
 
Delphi XE3 Enterprise
 
#10

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 12:40
@jfheins
Zitat:
*rofl* An der Stelle musste ich echt lachen
wieso, er erzeugt doch einen Clone
ClonedMsg := TApLogMessage.Create(Source);
Thomas Wassermann H₂♂
Das Problem steckt meistens zwischen den Ohren
DRY DRY KISS
H₂ (wenn bei meinen Snipplets nichts anderes angegeben ist Lizenz: WTFPL)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:00 Uhr.
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