Speicherlecks ohne Ende?

[BeS]

Hallo,
Ich habe mich gerade etwas mit valgrind beschäftigt und es gleich mal auf ein kleines GTKmm 'Hallo Welt' Programm angesetzt.

Das Programm:

Code: Alles auswählen

#include <gtkmm.h>

int main (int argc, char *argv[])
{
 Gtk::Main kit(argc, argv);

 Gtk::Window win;
 Gtk::Label label("Hallo Welt");
 win.add(label);
 label.show();

 Gtk::Main::run(win);

 return 0;
}

und das Ergebnis:

Code: Alles auswählen

==6718== LEAK SUMMARY:
==6718==    definitely lost: 36 bytes in 1 blocks.
==6718==    possibly lost:   800 bytes in 20 blocks.
==6718==    still reachable: 714291 bytes in 11350 blocks.
==6718==         suppressed: 0 bytes in 0 blocks.

Überrascht habe ich das gleiche mit einem Qt Programm versucht:

Code: Alles auswählen

#include <qapplication.h>
#include <qlabel.h>

int main( int argc, char **argv )
{
   QApplication a( argc, argv );
   QLabel hallo("Hallo Welt!", 0);
   a.setMainWidget( &hallo );
   hallo.show();
   return a.exec();
}

Das Ergebnis:

Code: Alles auswählen

==6785== LEAK SUMMARY:
==6785==    definitely lost: 284 bytes in 4 blocks.
==6785==    possibly lost:   0 bytes in 0 blocks.
==6785==    still reachable: 440551 bytes in 7235 blocks.
==6785==         suppressed: 200 bytes in 1 blocks.

Bei Qt sieht es also auch nicht viel besser aus.
Da stelle ich mir jetzt natürlich die Frage, ob ich etwas falsch gemacht habe oder ob wirklich beide Toolkits schon bei einem so kleinen Programm einiges an Speicher verlieren?

[gms]

ich habe schon einige Programme mit "valgrind" bearbeitet, die "36 bytes in 1 blocks" von GTKmm sind mir auch gleich bekannt vorgekommen.
Die gehen in der libc6 "verloren":

Hier die Ausgabe von "top -b -n1":

Code: Alles auswählen

==19247== 36 bytes in 1 blocks are definitely lost in loss record 4 of 17
==19247==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==19247==    by 0x1BA50976: (within /lib/tls/libc-2.3.2.so)
==19247==    by 0x1BA50218: __nss_database_lookup (in /lib/tls/libc-2.3.2.so)
==19247==    by 0x1BBA3AFB: ???

==19247== LEAK SUMMARY:
==19247==    definitely lost: 36 bytes in 1 blocks.
==19247==    possibly lost:   0 bytes in 0 blocks.
==19247==    still reachable: 61313 bytes in 139 blocks.
==19247==         suppressed: 0 bytes in 0 blocks.

Die Standardlibraries habe ich daher immer generös ignoriert

Grüße
gms

[BeS]

ist ja interessant. Also bei meinem GTKmm Testprogramm geht dann noch vielleicht etwas in der libglib verloren:

Code: Alles auswählen

==9446== 800 bytes in 20 blocks are possibly lost in loss record 91 of 122
==9446==    at 0x1B905901: calloc (vg_replace_malloc.c:176)
==9446==    by 0x1C0E4ACE: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.3)
==9446==    by 0x1C097CE6: (within /usr/lib/libgobject-2.0.so.0.600.3)
==9446==    by 0x1C098045: (within /usr/lib/libgobject-2.0.so.0.600.3)

Wie ernst sind denn die "possibly lost" zu nehmen?
Kann man da hoffen, dass sich valgrind täuscht oder ist es eher wahrscheinlich das sie auch weg sind?

Bei Qt sieht es aber schlechter aus. Hier geht auf jedenfall noch einiges in der xlib verloren.

Code: Alles auswählen

==9474== 216 bytes in 1 blocks are definitely lost in loss record 77 of 120
==9474==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==9474==    by 0x1C9667E2: _XimOpenIM (in /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2)
==9474==    by 0x1C09FE67: (within /usr/X11R6/lib/libX11.so.6.2)
==9474==    by 0x1C9660FE: _XimRegisterIMInstantiateCallback (in /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2)