Freigabe von Speicher scheitert

Hallo,
wenn ich von LV in einer DLL Speicher dynamisch reservieren lasse, aus diesem etwas lese, und diesen danach mit einer Funktion der DLL wieder freigebe, verschwinden die angezeigten Daten (logisch), aber Labview stürzt sofort darauf ab. Wieso?
Konkret habe ich eine Funktion, die mir ein Array dynamisch erzeugt, und in dieses Werte hineinschreibt. Diese lese ich mit Labview aus, und will nach dem Auslesen bei Beendigung des VI den Speicher wieder freigeben. Das Array zeigt darauf nichts mehr an, und das VI stürzt ab.
Wie kann ich dann das Array freigeben, um kein Speicherleck zu erhalten?
Vielen Dank!

Hallo lupus,

du hattest doch gerade erst eine längere Diskussion über den Umgang mit externen DLLs. Da wurde das doch auch schon besprochen!

Nicht, dass ich in dem Thema Experte wäre, aber die Stichworte MoveBlock & Speicherhandling fielen da schon...

Deine Beschreibung ist recht dünn.
Wie schon im letzten Thread, ein Upload eine VIs + DLL wäre nicht schlecht.

Ein weiterer Ansatz: Verwende anstatt der XNodes einmal den direkten DLL-Aufruf "MoveBlock". Da bin ich mir sicher, dass die Daten wirklich kopiert werden, IMHO solltest du dann auf gar keinen Fall ein Speicher-Problem haben.

Gruß, Jens

Ich habs lösen können, das Problem war offensichtlich, dass ich die externe Funktion zur Speicherfreigabe ohne Wartezeit aufgerufen habe, aber Labview anscheinend noch mit der Abarbeitung einiger anderer Programmteile nicht fertig war, die auf den nun nicht mehr existenten Speicher zugreifen wollten. Mit Wartezeit funktionierts nun.

Hallo lupus,

mal so ganz allgemein: Wenn ein Programm(-teil) nur durch zusätzlich eingefügte Wartezeiten funktioniert, dann ist meistens (immer?) etwas faul...

Wie führt denn LV eigentlich das Programm aus? Parallel, oder sequentiell von links nach rechts? Sofern parallel, kann es ja durchaus passieren, dass ein Teil des Codes den Speicher bereits löscht, während ein anderer noch daraus zugreift, oder?
Aber ich hänge einfach mal das VI, das ich habe, als Anhang an, sofern noch mehr dieser Fehler auftreten.
Vielen Dank!

Anzeige

Hallo lupus,

Zitat:Wie führt denn LV eigentlich das Programm aus? Parallel, oder sequentiell von links nach rechts?

Schon mal den Begriff DATAFLOW gehört?
- Ein Programmteil wird ausgeführt, wenn alle nötigen Daten bereitstehen.
- Daten werden per Draht transportiert.
- Wenn zwischen Programmteilen keine Datenabhängigkeit besteht, werden sie (quasi) parallel abgearbeitet.
- Likns/Rechts und Oben/Unten sind relativ. Man kann einen Monitor auch drehen

Autsch, das kann immer noch schief gehen, trotz Wait Funktion.
   
Du kannst überhaupt nicht vorhersagen, wann der "CleanUp" Aufruf ausgeführt wird. Der hängt einfach parallel zum Rest vom Code drinnen.
Die genaueren Hintergründe hat Gerd schon geschildert.


Gruß, Jens

Aber das würde doch meine These stützen: Wenn ein Teil des Programmes noch auf Daten zugreift, die ein anderes Programm ohne Wartezeit sofort löscht, gibt es einen Crash. Und damit ist doch eine gewisse Wartezeit nötig, oder?

Hallo lupus,

Zitat:Wenn ein Teil des Programmes noch auf Daten zugreift, die ein anderes Programm ohne Wartezeit sofort löscht, gibt es einen Crash

Symptombeobachtung: Korrekt.

Zitat:Und damit ist doch eine gewisse Wartezeit nötig, oder?

Analyse: Falsch.

Was du brauchst, ist DATAFLOW. Du musst eine explizite Abhängigkeit der Programmteile schaffen. Gern genutzt wird dafür ein ErrorCluster-Draht...

P.S.:
- Schön sind immer wieder Case-Strukturen, die vom Compiler wegoptimiert werden können. (TRUE-Konstante am Selektor)
- Schön auch die nicht-DATAFLOW-konforme "Wartezeit", die an dieser Stelle überhaupt nichts bringt, da sie parallel abgearbeitet wird...
THINK DATAFLOW!