INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Speicher läuft hoch



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

28.09.2007, 09:09
Beitrag #1

Nina Offline
LVF-Neueinsteiger


Beiträge: 4
Registriert seit: Feb 2007

8.00, 8.2.1, 2011
2006
kA

1169
Deutschland
Speicher läuft hoch
Hallo,

im folgenden versuche mein Problem einmal verständlich darzustellen.

Ich habe ein Prüfprogramm für Kameras zu entwickeln (Firewire und GigE). Die Schnittstelle zu den Kameras in .NET realisiert. Die Bilder werden über eine Callback gemeldet. Wenn ein Bild dargestellt werden soll, wird ein Bitmap-Objekt erzeugt und der Picture-Box zugewiesen. Scheinbar werden nicht mehr benötigte Objekte nicht aus dem Speicher gelöscht und auch "Speicherfreigabe anfordern" scheint nicht zu funktionieren. (Normalerweise braucht man sich bei .NET ja darum nicht zu kümmern)

Zur Lösung der Problems habe ich nun versucht nur ein Bitmap-Objekt anzulegen und mit Hilfe eines .NET-Programmes mit den aktuellen Bilddaten zu bearbeiten. Dieses aktualisierte Bitmap wird der Picture-Box zugewiesen. Nach einer Zeit stürzt die Bildausgabe mit der Ausschrift
"Die Bitmap ist bereits gesperrt" ab.

Fragen:
Wie kann ich nicht mehr verwendeter Speicher freigegeben werden?
Oder auf welche Weise kann ein Absturz der Bildausgabe verhindert werden?

Bin über jede Hilfe dankbar.
Viele Grüße Nina
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
28.09.2007, 09:30
Beitrag #2

Y-P Offline
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
LVF-Team

Beiträge: 12.612
Registriert seit: Feb 2006

Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN

71083
Deutschland
Speicher läuft hoch
Das mit dem Speicher kannst Du so wie im Anhang machen, habe ich aber so noch nie verwendet...., also einfach mal probieren.....

Gruß Markus


Angehängte Datei(en) Thumbnail(s)
   

--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
28.09.2007, 10:06
Beitrag #3

Nina Offline
LVF-Neueinsteiger


Beiträge: 4
Registriert seit: Feb 2007

8.00, 8.2.1, 2011
2006
kA

1169
Deutschland
Speicher läuft hoch
Hallo Markus,

vielen Dank für Deine Antwort, aber das habe ich schon probiert aber es hat nicht wirklich funktioniert.

Viele Grüße
Nina
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.09.2007, 19:07
Beitrag #4

rolfk Offline
LVF-Guru
*****


Beiträge: 2.302
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
Speicher läuft hoch
' schrieb:Das mit dem Speicher kannst Du so wie im Anhang machen, habe ich aber so noch nie verwendet...., also einfach mal probieren.....

Gruß Markus

Das funktioniert nur für Speicherblöcke die LabVIEW in VIs anlegt und beibehält um sie bei einer folgenden Ausführung dieses VIs wieder zu verwenden, statt sie gleich fortzuwerfen (was Zeit kostet) und sie danach wieder neu anfragen zu müssen, (was noch mehr Zeit braucht). Damit ist auch schon deutlich dass Request Memory Deallocation in den meisten Fällen nur eines tut, nämlich die Ausführungszeit eines LabVIEW Programmes zu verlangsamen!
Die Bereiche wo das eventuel sinnvoll ist, sind sehr eingeschränkt, etwa wenn ein VI nur einmal ausgeführt wird aber dabei eine riesige Array in einem Schieberegister (das man auch programmtechnisch selber leeren kann in der letzten Iteration) oder in einem Frontpanelkontrol zurücklässt. Ansonsten Finger weg von dieser Funktion!

Memory das von externem Code gemanaged wird (.Net, ActiveX, DLLs, Treiber etc.) kann LabVIEW sowieso auf keine einzige Weise ans System zurückgeben. Dass muss schon die Entität tun die es angefordert hat. Auch auf ein Memory Leak in LabVIEW selber, also ein echtes Leak wo LabVIEW aus irgendeinem Grund die Referenz zum Speicher verloren hat bevor es ans System zurückgegeben wurde, kann durch diese Funktion NICHT freigegeben werden. Dazu müsste LabVIEW einen komplett andere interne Speicherverwaltung haben mit einer mehr oder weniger komplizierten Garbage Collection. Aber Memory Leaks in LabVIEW selber sind wirklich extrem selten.

Und nein bei .Net braucht man sich nicht einfach nicht mehr um Speicher zu kümmern. Das stimmt vielleicht innerhalb eines C# Programms noch einigermassen, solange man nur managed Interfaces verwendet aber spätestens beim Übergang zu anderen Systemen (also auch im Zusammenhang mit LabVIEW oder Aufruf von unmanaged Interfaces wie WinAPI DLLs) kann .Net nicht jedesmal magisch wissen wann LabVIEW einen Datenbuffer nicht mehr nötig hat und LabVIEW kann auch nicht immer wissen ob eine .Net Komponente diesen Buffer noch weiter verwenden will. Der erwähnte Bildbuffer ist ein guter Kandidat für so ein Problem.

Rolf Kalbermatter

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Speicher läuft voll mittels .NET-Objekt mc_schleck 4 6.727 15.05.2018 08:48
Letzter Beitrag: mc_schleck

Gehe zu: