3. Matrizen (OpenCv) erstellen und wieder löschen

Matrizen (OpenCv) erstellen und wieder löschen

  • P

    Hallo zusammen,
    ich bin neu hier und habe gleich eine Frage an euch. Ich bastel gerade an einem Programm, in welchem ich Matrizen verwende. Je länger ich es laufen lasse desto mehr Speicher benötigt das Programm. Ich habe schon alle new-Operatoren abgegrast. Es gibt immer ein passendes delete.
    Meine Vermutung ist nun, dass es an den Matrizen liegt, die ich verwende. Ich habe schon das ganze Internet abgesucht, aber ich kann kein passendes Beispiel finden. Vielleicht könnt ihr mir ja helfen.

    In meiner Header-Datei steht ein Pointer des Typs CvMat:

    CvMat *matDiv;

    In der cpp-datei dann folgendes:

    matDiv = cvCreateMat(3, 3, CV_64FC1);
double nDiv[9] = {0.333,0,0, 0,0.333,0, 0,0,0.333};
cvInitMatHeader(matDiv, 3, 3, CV_64FC1, nDiv);

...
...

cvReleaseMat(&matDiv);

    Ist das so korrekt? Wird auch der ganze Speicher wieder freigegeben?

    Gruß,
    Philipp

    0
  • B

    Wenn es zu jedem 'cvCreateMat' auch ein 'cvReleaseMat' gibt, sollte das OK sein. Die Frage ist natürlich, was passiert an den Stellen mit '...'.

    Zum Testen könntest du ja auch mal ein Programm schreiben, welches einfach nur in einer Schleife 'cvCreateMat' und 'cvReleaseMat' aufruft und dabei den Speicherverbrauch beobachten.

    0
  • P

    Gute Idee.
    Habe das auch gleich mal gemacht:

    Die Matrix "Mat" steht im Headerfile

    int main(int argc, char* argv[])
{
	double Data[9] = {1,2,3,4,5,6,7,8,9};
	for (double i = 0; i<60000000; i++)
	{		
		Mat = cvCreateMat(3, 3, CV_64FC1);
		cvInitMatHeader( Mat, 3, 3, CV_64FC1, Data);

		cvReleaseMat(&Mat);
	}
	return 0;
}

    Gleiches Problem. Es scheint also wirklich an der Matrix zu liegen.

    Vielen Dank für deine schnelle Antwort.

    0
  • B

    Ich hab das spaßeshalber auch mal getestet (allerdings nur 599 mal...).
    Ergebnis mit 'valgrind' unter Linux:

    ==24810== malloc/free: in use at exit: 90,588 bytes in 603 blocks.
==24810== malloc/free: 1,335 allocs, 732 frees, 135,902 bytes allocated.
==24810==
==24810== searching for pointers to 603 not-freed blocks.
==24810== checked 204,504 bytes.
==24810==
==24810==
==24810== 86,256 bytes in 599 blocks are definitely lost in loss record 5 of 5
==24810==    at 0x40074B0: malloc (vg_replace_malloc.c:149)
==24810==    by 0x4115CB9: icvDefaultAlloc(unsigned, void*) (cxalloc.cpp:49)
==24810==    by 0x4DD5EEBB: (below main) (in /lib/i686/cmov/libc-2.5.so)
==24810==
==24810== LEAK SUMMARY:
==24810==    definitely lost: 86,256 bytes in 599 blocks.
==24810==      possibly lost: 0 bytes in 0 blocks.
==24810==    still reachable: 4,332 bytes in 4 blocks.
==24810==         suppressed: 0 bytes in 0 blocks.

    Ist die Lib nicht von Intel? 😮

    EDIT: Es scheint am 'cvInitMatHeader()' zu liegen. Läßt man das weg, ist alles OK bei valgrind.

    0
  • P

    Ja, das war auch meine Vermutung. CreateMat und InitMatHeader scheinen doppelt gemoppelt zu sein.
    Wenn ich die Matrix im Header nicht als Pointer sondern als "normale" CvMat definiere, kann ich mir das CreateMat sparen und dann läuft auch alles bestens. Aber 100%ig kann ich es nicht erklären.
    Ja das ist die "Computer-Vision-Libary" von Intel. Bin bisher stark begeistert davon.

    0
Anmelden zum Antworten