Fehler mit externer DLL, Callback-Funktionen.

[Rainer Wolff]

Hallo,

seit etlichen Tagen kämpfe ich mit einer externen Kommunikations-DLL.

Es handelt sich um eine DLL zur OPC-UA Kommunikation (SPS), das Projekt open62541. Die DLL ist in C geschrieben, ich habe einen eigenen Pascal-Wrapper drum herum gebaut. Es gibt Lese- und Schreibbefehle, und auch einige Callback-Funktionen für Verbindungsstatus und Wertänderungen aus der SPS heraus

Grundfunktionen laufen, Daten lesen, schreiben, Wertänderungen etc. Etliche Testprogramme, die einzelne Funktionen testen, laufen über einen längeren Zeitraum.

Sobald ich aber das ganze in meinem Gesamtprojekt integriere, erhalte ich nach einigen Durchläufen unerklärliche Kommunikationabbrüche bzw. Fehlermeldungen.
z.B. wird ein Schreibbefehl in die DLL während des Aufrufs durch ein Callback der Wertänderung eines anderen Feldes unterbrochen und kehrt nie mehr zurück.
An anderer Stelle wurde eine Funktion beim Aufruf der DLL rekursiv wieder aufgerufen.

Meine Vermutung geht ja dahin, daß ich irgendwo im Wrapper noch Fehler habe, so daß irgendwelche Speicherinhalte willkürlich verändert werden.

Wer kann mir vielleicht Tipps und Hinweise für Tools geben, um diese Fehler einzugrenzen.

[shebang]

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := True

hast du bereits gesetzt?

[Der schöne Günther]

Hey, genau das Problem hatte ich auch mit open62541.

Da hat ständig irgendwas nicht gepasst, unerklärliche Speicherfehler obwohl das Pascal-Wrapping definitiv richtig war. Dann mal einen FreePascal-Compiler probiert, mit dem lief es viel besser. Aber auch nur bis zu einem bestimmten Grad, dann war wieder Sense.

Seit ca. einem Jahr haben wir nun open62541 fest in unserer Anwendung drin und es läuft sehr gut. Aber nicht mehr mit Delphi. Wir haben es mit C++ umgesetzt. Es ist ein separater Prozess, die Kommunikation mit der Delphi-Anwendung läuft über http/REST. Funktioniert fantastisch und war im Endeffekt weniger Arbeit als gedacht.

Muss auch nichts kosten, Visual Studio Code und die Gnu-Compiler sind ja alle komplett kostenlos.


PS: Ich sehe jetzt erst, dass du die eigentliche open62541-Logik ja schon in C umgesetzt hast statt Delphi. Und du stattdessen nur ein paar Routinen nach außen exportierst. Wäre trotzdem interessant was und wie, denn das sollte mit open62541 im Endeffekt ja gar nichts mehr zu tun haben.
Trotzdem bleibe ich bei der Empfehlung so etwas vielleicht wirklich als separaten Prozess statt DLL zu realisieren, hat einfach viel mehr Vorteile und das bisschen Mehr an Ressourcenverbrauch ist völlig unerheblich.

[Rainer Wolff]

Zitat:

Zitat von shebang (Beitrag 1498779)

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := True

hast du bereits gesetzt?

Schon lange, wobei ich zugebe, einige Leaks bisher großzügig ignoriert zu haben, da mir wurst war, ob ein paar Delphi-Objekte vielleicht zu viel Speicher belegen.
Den Fehler würde ich eher zwischen DLL und Delphi vermuten, da erzählt ReportMemoryLeaks meiner Ansicht nach nicht genug, vielleicht kenne ich mich da aber auch zu schlecht aus.

Inzwischen habe ich FastMM4 an den Start gebracht, auch ein paar Delphi-Leaks aufgeräumt und jetzt ein neues Problem an ganz anderer Stelle:

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

[jaenicke]

Zitat:

Zitat von Rainer Wolff (Beitrag 1498794)

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

Das kann (!) darauf hindeuten, dass im Speicher etwas richtig schief geht, was auch die anderen Probleme erklären würde. Denn FastMM überschreibt ungültigen Speicher teilweise, so dass z.B. Zugriffe auf Speicherbereiche schon freigegebener Objekte nicht mehr die (vorher noch vorhandenen und nur als gelöscht markierten) Werte liefern.
Außerdem ist das Speicherlayout bei einem anderen Speichermanager anders, so dass auch dadurch vorher verdeckte Probleme Wirkung zeigen können.

Aber gerade bei solchen unspezifischen Problemen gibt es sehr viele mögliche Ursachen, was dir vermutlich auch klar ist. Das geht bei simplen Sachen los wie falsche Aufrufkonventionen, die du sicherlich aber schon geprüft hast.

Wenn man Speicherstellen identifizieren kann, die offenbar später falsche Werte bekommen, sind z.B. Datenhaltepunkte eine Möglichkeit um die Änderung mitzubekommen. Von außen ist es aber schwer konkrete Tipps zu geben.

[Rainer Wolff]

Zitat:

Zitat von jaenicke (Beitrag 1498795)

Zitat:

Zitat von Rainer Wolff (Beitrag 1498794)

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

Das kann (!) darauf hindeuten, dass im Speicher etwas richtig schief geht, was auch die anderen Probleme erklären würde. Denn FastMM überschreibt ungültigen Speicher teilweise, so dass z.B. Zugriffe auf Speicherbereiche schon freigegebener Objekte nicht mehr die (vorher noch vorhandenen und nur als gelöscht markierten) Werte liefern.
Außerdem ist das Speicherlayout bei einem anderen Speichermanager anders, so dass auch dadurch vorher verdeckte Probleme Wirkung zeigen können.

ok, das war mein eigener Bockmist (nicht initialisierter Funktionsrückgabewert), erstaunlich, dass das erst jetzt herauskommt

[dummzeuch]

Vorweg: Ich kenne diese spezielle DLL nicht. Alles hier bezieht sich auf generelle Aufrufe von DLLs zur Kommunikation mit Hardware.

Ein üblicher Fehler bei solchen Umsetzungen ist eine fehlende oder falsche Angabe der Calling Convention. Wenn die DLL in C geschrieben ist, vermutlich "cdecl". Aber das hast Du vermutlich schon überprüft.

Ansonsten könnte es evtl. sein, dass Du in Callbacks die VCL aufrufst. Da die Callbacks in einem anderen Threadkontext als dem des Hauptthreads erfolgen können, sollte man das definitiv nicht tun.

[Rainer Wolff]

Zitat:

Zitat von dummzeuch (Beitrag 1498829)

Ein üblicher Fehler bei solchen Umsetzungen ist eine fehlende oder falsche Angabe der Calling Convention. Wenn die DLL in C geschrieben ist, vermutlich "cdecl". Aber das hast Du vermutlich schon überprüft.

Ansonsten könnte es evtl. sein, dass Du in Callbacks die VCL aufrufst. Da die Callbacks in einem anderen Threadkontext als dem des Hauptthreads erfolgen können, sollte man das definitiv nicht tun.

Klar, cdecl ist drin. Wie geschrieben, die Grundfunktionen laufen grundsätzlich, auch in Schleife mit x Durchläufen. Erst, wenn ich das ganze im fertigen Programm zusammenpacke und an verschiedenen Enden gleichzeitig Sachen passieren, dann knallt es.

Ich habe jetzt auch versucht, die Ergebnisse des Callbacks in eine Queue zu schreiben und per Timer abzuarbeiten, jetzt knallt es wieder an ganz anderer Stelle, wo vorher nie Probleme auftraten.