Fehler beim Schließen des VIs nach Delphi-DLL-Aufruf

Hallo,

ein etwas nebulöses Problem:

ich arbeite mit LabVIEW 8.5.1 und rufe diverse Funktionen einer Delphi-DLL mit "Call Library Function Node" auf (stdcall), was soweit auch ganz gut funktioniert. Um zunächst die Parameterübergabe zu testen, hatte mein Kollege in der DLL-Testversion keine Inhalte programmiert, sondern lediglich die Parameterlisten überprüft und Ausgabewerte zurück gegeben, incl. Funktionswert. Lief alles so, wie wir uns das vorgestellt hatten.

Die nächste DLL-Testversion rief ihrerseits eine andere benötigte DLL auf. Auch kein Problem.

Nächste Steigerung: jetzt werden die Original-Funktionen mit den selben Funktionsköpfen wie bisher verwendet. Dazu muss die Datei borlandmm.dll installiert werden. Alle Funktionen arbeiten zwar wie gewollt, aber jedes Mal, wenn ich ein VI, das einen Funktionsaufruf enthält, schließe, erhalte ich die Fehlermeldung:
"Die Anweisung in 0x00000000 verweist auf Speicher in 0x00000000. Der Vorgang read konnte nicht auf dem Speicher durchgeführt werden."
Die Meldung erscheint übrigens auch, wenn man das VI gar nicht ausführt, sondern nur öffnet und wieder schließt. Auch die einfachen Test-Funktionen (Integer hin und her reichen etc.), die in der neuen DLL-Version nicht verändert wurden, reagieren nun so. Quittiert man allerdings die Fehlermeldung mit Ok, bleibt LabVIEW arbeitsfähig.

Ich bin ein bisschen ratlos, wer nun wo suchen muss. Da ich seit der letzten, funktionierenden Version auf meiner Seite nichts geändert habe, neige ich dazu, den Fehler in der DLL zu suchen. Nur wo? Was passiert denn genau beim Schließen eines DLL-aufrufenden VIs? Leider ist die DLL "historisch gewachsen", also wenig übersichtlich, und posten darf ich sie auch nicht. Mein Kollege meinte aber, dass es hin und wieder auch in der Delphi-Umgebung damit Probleme gäbe, und diese eher auf Maschinen mit Intel-Prozessoren. Diese Info würde ich aber mit Vorsicht genießen.

Vielleicht hat von euch ja jemand eine Idee oder kann mir erklären, was in welcher Reihenfolge beim Schließen eines VIs geschieht, damit wir dieses verflixte Ding doch noch zum Laufen bringen.

Erstmal vielen Dank fürs Lesen,
Bärbel

Anzeige

' schrieb:Dazu muss die Datei borlandmm.dll installiert werden.

MemoryManager?
Welche Typen haben denn die Parameter in den Funktionsaufrufen? Ich hoffe mal, da sind kein Strings dabei? Und erstrecht keine Instanzen? In DLL's sollten nur Basistypen wie Int32, Double, PChar (Pointer) etc vorkommen.

Werden in der DLL Instanzen erzeugt? Mit welcher Delphi-Version ist denn die DLL geschrieben.

Zitat:Fehlermeldung:
"Die Anweisung in 0x00000000 verweist auf Speicher in 0x00000000. Der Vorgang read konnte nicht auf dem Speicher durchgeführt werden."

Nicht initialisierter Pointer oder ein Pointer der noch in der Liste steht, aber nicht mehr vorhanden ist. Etc.

Zitat:Mein Kollege meinte aber, dass es hin und wieder auch in der Delphi-Umgebung damit Probleme gäbe, und diese eher auf Maschinen mit Intel-Prozessoren. Diese Info würde ich aber mit Vorsicht genießen.

Mit großer Vorsicht, mit sehr großer Vorsicht. Du wärst die Erste, die da einen Fehler gefunden hat.

Zitat:Vielleicht hat von euch ja jemand eine Idee oder kann mir erklären, was in welcher Reihenfolge beim Schließen eines VIs geschieht, damit wir dieses verflixte Ding doch noch zum Laufen bringen.

Was beim Schließen eines VI's mit einer DLL alles gemacht wird, weiß ich nicht.


Ich tippe darauf, dass entweder in der DLL ein Fehler ist, oder ein Funktionsaufruf mangelhaft ausgeführt wurde. Wenn der Fehler erst auftrat, nachdem BorlandMM.DLL istalliert sein musste, tippe ich sehr auf den MemoryManager. Die MM's von Delphi (nicht mehr Borland, auch nicht mehr Codegear, jetzt Embarcadero) und LV sind nicht kompatibel. Strings und Instanzen würde ich nicht verwenden.

Eins hab ich nich vergessen: Ist ShareMem (in der DLL) eingebunden? An allererster Stelle?

Hallo IchSelbst (klingt irgendwie ein bisschen schizo...),

' schrieb:MemoryManager?
Welche Typen haben denn die Parameter in den Funktionsaufrufen? Ich hoffe mal, da sind kein Strings dabei? Und erstrecht keine Instanzen? In DLL's sollten nur Basistypen wie Int32, Double, PChar (Pointer) etc vorkommen.

Nach anfänglichen Schwierigkeiten sind wir dazu übergegangen, ausschließlich 4 und 8 Byte breite Basistypen zu verwenden, um genau zu sein: I32, U32 und Double.

' schrieb:Werden in der DLL Instanzen erzeugt? Mit welcher Delphi-Version ist denn die DLL geschrieben.
Nicht initialisierter Pointer oder ein Pointer der noch in der Liste steht, aber nicht mehr vorhanden ist. Etc.

Ich weiß nicht viel über die DLL, das wird hier etwas ... mmh ... personengebunden gehandhabt. Aber schlaue Fragen kann ich natürlich stellen und auch tolle Tipps weitergeben :-) Ich werde mich nach der Delphi-Version erkundigen, ich meine mal was von "Delphi 7" gehört zu haben, aber sicher bin ich nicht.

' schrieb:Wenn der Fehler erst auftrat, nachdem BorlandMM.DLL istalliert sein musste, tippe ich sehr auf den MemoryManager. Die MM's von Delphi (nicht mehr Borland, auch nicht mehr Codegear, jetzt Embarcadero) und LV sind nicht kompatibel. Strings und Instanzen würde ich nicht verwenden.

Das macht mich jetzt nicht wirklich glücklich. Werde ich aber mal so weiter geben.

Danke erstmal,
Bärbel

' schrieb:(klingt irgendwie ein bisschen schizo...),

Irgendwelche Spuren müssen ein viertel Jahrhundert mit Software doch hinterlassen.

Zitat:Nach anfänglichen Schwierigkeiten sind wir dazu übergegangen, ausschließlich 4 und 8 Byte breite Basistypen zu verwenden, um genau zu sein: I32, U32 und Double.

Das ist doch schon mal sehr gut.

Zitat:das wird hier etwas ... mmh ... personengebunden gehandhabt.

Ich hoffe die Personenbindung schließt nicht solche Programmiertricks ein wie z.B. einen - möchtegern - Pointer mal so eben als U32 zu übergeben.

Zitat:ich meine mal was von "Delphi 7" gehört zu haben,

D7Pro/Ent gehört zu den Topversionen was die Fehlerfreiheit etc. betrifft!


Und vergiss die Sache mit dem ShareMem nicht (siehe Beitrag #3)!

' schrieb:Irgendwelche Spuren müssen ein viertel Jahrhundert mit Software doch hinterlassen.

' schrieb:Ich hoffe die Personenbindung schließt nicht solche Programmiertricks ein wie z.B. einen - möchtegern - Pointer mal so eben als U32 zu übergeben.

Nö, keine Tricks, kein doppelter Boden.

' schrieb:D7Pro/Ent gehört zu den Topversionen was die Fehlerfreiheit etc. betrifft!
Und vergiss die Sache mit dem ShareMem nicht (siehe Beitrag #3)!

Ich habe eine schöne, lange Mail mit allen Fragen und Anmerkungen an meinen Kollegen geschickt und warte auf Antwort. Die Sache mit ShareMem hab ich ihn auch gefragt. Wenn ich Bescheid habe, werde ich die Infos weitergeben. Soweit ich weiß, hat er aber momentan Urlaub, was soviel heißt, dass er von zu Hause aus arbeitet. (Die letzte DLL-Version war von gestern, 22 Uhr...)

Bis dahin,
Bärbel

Hallo,

mein Kollege sagt:
"Wir verwenden Borland Delphi 2006.
Das ShareMem-Modul ist (an allererster Stelle) in der DLL eingebunden.

Das mit den Strings versuchen wir zwar zu vermeiden, aber leider klappt
das nicht immer. Und eigentlich ist ShareMem dazu gedacht genau diese
Probleme mit Strings zu lösen. Normalerweise funktioniert das auch ganz
gut. Aber vielleicht gibt es im Zusammenspiel mit LabVIEW zusätzliche
Einschränkungen."

Gebe ich jetzt erstmal kommentarlos weiter. Schade, dass doch nicht Delphi 7 verwendet wird.
(Na ja, das war jetzt *fast* kommentarlos.)

Grüße,
Bärbel

' schrieb:"Wir verwenden Borland Delphi 2006.

Selber Schuld.
Das entspricht so ungefähr LV-80. (Naja so ungefähr. Wenn in LV 100% Fehler drin sind, dann sind in D2006 1% Fehler). Ich würde empfehlen auf D2k7Win32 upzudaten. Ob in D2006 der MemoryManager selbst schwerwiegende Fehler hat, weiß ich nicht.

Zitat:Das mit den Strings versuchen wir zwar zu vermeiden, aber leider klappt das nicht immer.

Das klappt immer.
(Ansi-)Strings in Delphi und Strings in LV sind verschiedene Sachen. Strings kann man immer durch PChar ersetzen. Das ist zwar etwas aufwändig, aber garantiert sicher.

Zitat:Und eigentlich ist ShareMem dazu gedacht genau diese Probleme mit Strings zu lösen.

Im Falle, wenn in beiden Systemen - Applikation und DLL, also LV und Delphi - der selbe Speichermanager verwendet wird. Und genau das ist nicht der Fall. Deswegen nützt in Bezug auf die Einbindung in LV ShareMem an sich nichts. Das steht in Bezug auf LV nur als Sicherheit drinnen.

Ich rate grundsätzlich zu PChar und den Rest von Hand zu machen.

Hinweis:
Auch dynamische Arrays, erst recht wenn sie mehrdimensional sind, sind nicht kompatibel.

Hallo,

späte Antwort, ich weiß. Das liegt daran, dass wir das Problem immer noch nicht näher einkreisen konnten.

zu Delphi 2006:

' schrieb:Selber Schuld.
Das entspricht so ungefähr LV-80. (Naja so ungefähr. Wenn in LV 100% Fehler drin sind, dann sind in D2006 1% Fehler). Ich würde empfehlen auf D2k7Win32 upzudaten. Ob in D2006 der MemoryManager selbst schwerwiegende Fehler hat, weiß ich nicht.

Es gibt zu dieser Version inzwischen diverse Bug- und Hotfixes, durch die die bekannten Fehler behoben sein sollen. Die meint man hier alle eingespielt zu haben.

' schrieb:Das klappt immer.
(Ansi-)Strings in Delphi und Strings in LV sind verschiedene Sachen. Strings kann man immer durch PChar ersetzen. Das ist zwar etwas aufwändig, aber garantiert sicher.

Ich bin vollkommen deiner Meinung, aber das liegt nicht in meiner Hand. Die DLL wird aus einer Software extrahiert, die schon lange im Dienst ist. Das allerdings nur mit kompletter Delphi-Umgebung, bisher hat noch niemand Einzelteile benötigt. Die derzeitigen Betreuer sind der Ansicht, dass irgendwo auch noch ganz "normale" Speicherfehler stecken könnten. Man sucht...

Sollte sich noch irgendeine grundsätzliche Erkenntnis ergeben, die für dieses Forum interessant ist, werde ich sie hier posten. Ansonsten bedanke ich mich - auch stellvertretend für meine Kollegen - fürs Lesen, Mitdenken und Antworten.

Viele Grüße,
Bärbel

' schrieb:Die derzeitigen Betreuer sind der Ansicht, dass irgendwo auch noch ganz "normale" Speicherfehler stecken könnten. Man sucht...

"Die Anweisung in 0x00000000 verweist auf Speicher in 0x00000000." könnte bedeuten, dass eine Instanz, die mit Create(self) erzeugt wurde, manuell gefreed wurde. Was falsch ist. Dumm nur, dass der darauf resultierende Fehler nicht immer auftritt.

Oder einen hat einen globalen String-Pointer einfach auf nil gesetzt. ...