QDomNode: Speicher wird beim Löschen nicht freigegeben

Hundefutter · Beitrag von **Hundefutter** » 21. Juli 2009 15:18

Hallo.

Ich hätte da mal eine Frage zum Löschen / Freigeben von QDomNode-Objekten:

Ich habe ein eigenes Dom-Model und ein Objekt DomItem, welche QDomNodes zu einer Struktur zusammensetzen, so dass ich sie in einer QTreeView anzeigen kann.

Nun habe ich mal einige Objekte erstellt (ca. 10.000), so dss mein Programm ein paar MB Speicher belegt hat. Wenn ich nun diese Objekte wieder lösche, sinkt der Speicherverbrauch meines Programms nicht wieder.
Jetzt ist die Frage, ob ich beim Löschen einen Fehler mache, also den Speicher nicht wieder richtig freigebe, oder ob Qt den Speicher nicht wieder hergibt und noch behält.

Hier mal meine Löschen-Funktion:

Code: Alles auswählen

void DomModel::remove(const QModelIndex &index)
{
	DomItem* tmpItem = static_cast<DomItem*>(index.internalPointer());

	this->beginRemoveRows(index.parent(),tmpItem->row(),tmpItem->row());
	tmpItem->node().parentNode().removeChild(tmpItem->node());
	tmpItem->parent()->clearCache();
	this->endRemoveRows();
}

Was meint ihr dazu? Ist meine remove-Funktion so ok oder räume ich nicht richtig auf?

Mit freundlichen Grüßen
Hundefutter

CaptnChaos · Beitrag von **CaptnChaos** » 21. Juli 2009 15:27

Falls DomItem eine subclass von QObject ist, ruf tmpItem->deleteLater() auf, sonst delete tmpItem.

upsala · Beitrag von **upsala** » 21. Juli 2009 20:07

Wer sagt, daß dein Programm den Speicher nicht mehr freigibt? Hast du das schon mal mit valgrind überprüft?

Hundefutter · Beitrag von **Hundefutter** » 22. Juli 2009 14:12

upsala hat geschrieben:Wer sagt, daß dein Programm den Speicher nicht mehr freigibt? Hast du das schon mal mit valgrind überprüft?

Unter Linux hat man einen Systemmonitor, der die einzelnen Prozesse und deren Speicherverbrauch anzeigt. Dabei kann ich den Speicherverbraucht verfolgen. Dieser steigt, wenn ich neue Element einfüge, sinkt jedoch nicht wieder, wenn ich diese Element wieder lösche...

Der Hinweis mit "delete tmpItem" und "tmpItem->deleteLater()" (wenn DomItem Subclass von QObject) bringt leider keine Veränderung.

Könnt ihr mir noch weiter Hinweise geben, woran es liegen könnte, dass er den Arbeitsspeicher nicht wieder freigibt?

Mit freundlichen Grüßen
Hundefutter

DarkWotan · Beitrag von **DarkWotan** » 22. Juli 2009 14:26

Wenn du mal testweise in einer einfachen main-Funktion ein größeres Array definierst, etwas wartest, es wieder freigibst und nochmal wartest, was zeigt dir der Systemmonitor dann an?

Beitrag von **Christian81** » 22. Juli 2009 14:54

Benutze valgrind und schau ob der Speicher wirklich nicht freigegeben wird und fertig!

Hundefutter · Beitrag von **Hundefutter** » 22. Juli 2009 16:13

So, habe mal einen Testlauf mit valgrind gemacht und dabei 3 neue Element eingefügt und wieder gelöscht, danach beendet.
Kann man valgrind auch nur bis zu einem bestimmten Punkt im Programm laufen lassen, also nur bis zu dem Zeitpunkt, wo ich die Elemente wieder gelöscht habe?

Hier meine Ausgabe nach dem Beenden von valgrind:

==3905== Memcheck, a memory error detector.
==3905== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==3905== Using LibVEX rev 1884, a library for dynamic binary translation.
==3905== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==3905== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==3905== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==3905== For more details, rerun with: -v
==3905==
==3905==
==3905== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3226 from 7)
==3905== malloc/free: in use at exit: 1,638,210 bytes in 12,768 blocks.
==3905== malloc/free: 131,445 allocs, 118,677 frees, 16,791,823 bytes allocated.
==3905== For counts of detected errors, rerun with: -v
==3905== searching for pointers to 12,768 not-freed blocks.
==3905== checked 2,204,888 bytes.
==3905==
==3905== 4 bytes in 1 blocks are definitely lost in loss record 4 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x80517E5: loadDomFromFile(QString const&) (DomFunctions.h:11)
==3905== by 0x8051A35: Todo_dialog::Todo_dialog(QWidget*) (todo_dialog.cpp:16)
==3905== by 0x805500B: main (main.cpp:9)
==3905==
==3905==
==3905== 20 bytes in 1 blocks are possibly lost in loss record 30 of 224
==3905== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3905== by 0x519D265: FcPatternObjectAddWithBinding (fcpat.c:479)
==3905== by 0x519DA0B: FcPatternObjectAdd (fcpat.c:545)
==3905== by 0x5199AB8: FcFontRenderPrepare (fcmatch.c:453)
==3905== by 0x5199CB7: FcFontSetMatch (fcmatch.c:538)
==3905== by 0x5199EBC: FcFontMatch (fcmatch.c:560)
==3905== by 0x5FEFBBA: pango_fc_fontset_get_font_at (pangofc-fontmap.c:761)
==3905== by 0x5FEFEF0: pango_fc_fontset_foreach (pangofc-fontmap.c:1003)
==3905== by 0x60286D6: pango_fontset_foreach (pango-fontset.c:101)
==3905== by 0x5FF0A03: pango_fc_font_map_load_font (pangofc-fontmap.c:1677)
==3905== by 0x6027B9E: pango_font_map_load_font (pango-fontmap.c:94)
==3905== by 0x6025247: get_shaper_and_font (pango-context.c:1093)
==3905==
==3905==
==3905== 5,802 (32 direct, 5,770 indirect) bytes in 1 blocks are definitely lost in loss record 67 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x4B3009F: QHashData::detach_helper(void (*)(QHashData::Node*, void*), int) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x40A2008: (within /usr/lib/libQtXml.so.4.5.0)
==3905== by 0x40A219B: (within /usr/lib/libQtXml.so.4.5.0)
==3905== by 0x40955DC: (within /usr/lib/libQtXml.so.4.5.0)
==3905== by 0x804D75E: DomModel::insert(QModelIndex const&) (dommodel.cpp:199)
==3905== by 0x80513B8: Todo_dialog::insertTask() (todo_dialog.cpp:69)
==3905== by 0x8051407: Todo_dialog::Test() (todo_dialog.cpp:77)
==3905== by 0x8051424: Todo_dialog::editTaskButton() (todo_dialog.cpp:58)
==3905== by 0x8055256: Todo_dialog::qt_metacall(QMetaObject::Call, int, void**) (moc_todo_dialog.cpp:72)
==3905== by 0x4C16CA7: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4C170DF: QMetaObject::activate(QObject*, QMetaObject const*, int, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905==
==3905==
==3905== 92 (68 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 75 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x4C14C70: QObject::QObject(QObject*) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x80536E2: DomItem::DomItem(QDomNode&, int, DomItem*) (domitem.cpp:5)
==3905== by 0x8053914: DomItem::child(int) (domitem.cpp:37)
==3905== by 0x804DEE2: DomModel::index(int, int, QModelIndex const&) const (dommodel.cpp:132)
==3905== by 0x47C886A: QTreeView::rowsInserted(QModelIndex const&, int, int) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4786245: QAbstractItemView::qt_metacall(QMetaObject::Call, int, void**) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x47CD299: QTreeView::qt_metacall(QMetaObject::Call, int, void**) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4C16CA7: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4C17931: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4C5191E: QAbstractItemModel::rowsInserted(QModelIndex const&, int, int) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4BFB9E2: QAbstractItemModel::endInsertRows() (in /usr/lib/libQtCore.so.4.5.0)
==3905==
==3905==
==3905== 1,680 (96 direct, 1,584 indirect) bytes in 4 blocks are definitely lost in loss record 81 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x80538F1: DomItem::child(int) (domitem.cpp:37)
==3905== by 0x804DEE2: DomModel::index(int, int, QModelIndex const&) const (dommodel.cpp:132)
==3905== by 0x47C886A: QTreeView::rowsInserted(QModelIndex const&, int, int) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4786245: QAbstractItemView::qt_metacall(QMetaObject::Call, int, void**) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x47CD299: QTreeView::qt_metacall(QMetaObject::Call, int, void**) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4C16CA7: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4C17931: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4C5191E: QAbstractItemModel::rowsInserted(QModelIndex const&, int, int) (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x4BFB9E2: QAbstractItemModel::endInsertRows() (in /usr/lib/libQtCore.so.4.5.0)
==3905== by 0x804DA3E: DomModel::insert(QModelIndex const&) (dommodel.cpp:205)
==3905== by 0x80513B8: Todo_dialog::insertTask() (todo_dialog.cpp:69)
==3905==
==3905==
==3905== 148 (128 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 84 of 224
==3905== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3905== by 0x519C9D6: FcPatternObjectInsertElt (fcpat.c:367)
==3905== by 0x519D3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==3905== by 0x519D4DE: FcPatternAppend (fcpat.c:991)
==3905== by 0x51A2FBE: FcEndElement (fcxml.c:2023)
==3905== by 0x5358EC3: (within /usr/lib/libexpat.so.1.5.2)
==3905== by 0x5359C10: (within /usr/lib/libexpat.so.1.5.2)
==3905== by 0x535B5EE: (within /usr/lib/libexpat.so.1.5.2)
==3905== by 0x535BCE6: (within /usr/lib/libexpat.so.1.5.2)
==3905== by 0x535268B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==3905== by 0x51A0EFD: FcConfigParseAndLoad (fcxml.c:2552)
==3905== by 0x51A1245: FcConfigParseAndLoad (fcxml.c:2438)
==3905==
==3905==
==3905== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 85 of 224
==3905== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3905== by 0x4F2D548: (within /lib/tls/i686/cmov/libc-2.9.so)
==3905== by 0x4F2DE25: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.9.so)
==3905== by 0x5A40F5B: ???
==3905== by 0x5A41CBE: ???
==3905== by 0x4ED3811: getpwnam_r (in /lib/tls/i686/cmov/libc-2.9.so)
==3905== by 0x5131E71: g_get_any_init_do (gutils.c:1631)
==3905== by 0x5133924: g_get_home_dir (gutils.c:1782)
==3905== by 0x59AA524: ORBit_option_parse (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59B100F: CORBA_ORB_init (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x596A66E: gconf_orb_get (in /usr/lib/libgconf-2.so.4.1.5)
==3905== by 0x596A7FD: (within /usr/lib/libgconf-2.so.4.1.5)
==3905==
==3905==
==3905== 60 bytes in 1 blocks are possibly lost in loss record 97 of 224
==3905== at 0x40270FC: realloc (vg_replace_malloc.c:429)
==3905== by 0x5105169: g_realloc (gmem.c:170)
==3905== by 0x59B76B0: ORBit_realloc_tcval (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59BBC86: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x62F9B31: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62FDD83: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62FE1CD: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62B1D2C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==3905== by 0x62B1EDB: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==3905== by 0x616BA09: atk_bridge_init (bridge.c:217)
==3905== by 0x5BC2B4C: default_display_notify_cb (gtkmodules.c:417)
==3905== by 0x5064ABB: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)
==3905==
==3905==
==3905== 129 bytes in 8 blocks are possibly lost in loss record 114 of 224
==3905== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3905== by 0x5105283: g_malloc (gmem.c:131)
==3905== by 0x59B77AF: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59B7478: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59BBAC4: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59BB92D: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x59BBC4E: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==3905== by 0x62F9B31: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62FDD83: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62FE1CD: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==3905== by 0x62B1D2C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==3905== by 0x62B1EDB: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==3905==
==3905==
==3905== 252 (4 direct, 248 indirect) bytes in 1 blocks are definitely lost in loss record 124 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x80519A2: Todo_dialog::Todo_dialog(QWidget*) (todo_dialog.cpp:12)
==3905== by 0x805500B: main (main.cpp:9)
==3905==
==3905==
==3905== 4,460 (1,024 direct, 3,436 indirect) bytes in 3 blocks are definitely lost in loss record 188 of 224
==3905== at 0x40270FC: realloc (vg_replace_malloc.c:429)
==3905== by 0x519C951: FcPatternObjectInsertElt (fcpat.c:358)
==3905== by 0x519D3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==3905== by 0x519DA0B: FcPatternObjectAdd (fcpat.c:545)
==3905== by 0x519DA4F: FcPatternObjectAddBool (fcpat.c:691)
==3905== by 0x5191E25: FcDefaultSubstitute (fcdefault.c:136)
==3905== by 0x5ED8967: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:93)
==3905== by 0x5FED3D4: pango_fc_default_substitute (pangofc-fontmap.c:1586)
==3905== by 0x5FF05FE: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1640)
==3905== by 0x6027AD5: pango_font_map_load_fontset (pango-fontmap.c:136)
==3905== by 0x6025881: itemize_state_process_run (pango-context.c:1289)
==3905== by 0x6025E1E: pango_itemize_with_base_dir (pango-context.c:1467)
==3905==
==3905==
==3905== 1,576 (16 direct, 1,560 indirect) bytes in 1 blocks are definitely lost in loss record 190 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x8051B93: Todo_dialog::Todo_dialog(QWidget*) (todo_dialog.cpp:24)
==3905== by 0x805500B: main (main.cpp:9)
==3905==
==3905==
==3905== 216 bytes in 1 blocks are definitely lost in loss record 197 of 224
==3905== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3905== by 0x5227012: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==3905== by 0x5226E4F: _XimRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==3905== by 0x520B037: XRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==3905== by 0x4834096: (within /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4832B90: QInputContextFactory::create(QString const&, QObject*) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4208BB4: QApplication::inputContext() const (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x4252BC7: QWidgetPrivate::inputContext() const (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x425651A: QWidget::inputContext() (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x420F9E8: QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x425961D: QWidget::setFocus(Qt::FocusReason) (in /usr/lib/libQtGui.so.4.5.0)
==3905== by 0x420FF93: QApplication::setActiveWindow(QWidget*) (in /usr/lib/libQtGui.so.4.5.0)
==3905==
==3905==
==3905== 129,704 bytes in 107 blocks are possibly lost in loss record 222 of 224
==3905== at 0x4024EFA: memalign (vg_replace_malloc.c:460)
==3905== by 0x4024FAE: posix_memalign (vg_replace_malloc.c:569)
==3905== by 0x511AA02: slab_allocator_alloc_chunk (gslice.c:1136)
==3905== by 0x511C1E2: g_slice_alloc (gslice.c:666)
==3905== by 0x50D589E: g_array_sized_new (garray.c:86)
==3905== by 0x50D59B6: g_array_new (garray.c:78)
==3905== by 0x5127A8B: g_static_private_set (gthread.c:451)
==3905== by 0x50E540F: g_get_filename_charsets (gconvert.c:1185)
==3905== by 0x50E5480: _g_convert_thread_init (gconvert.c:1290)
==3905== by 0x5127D2C: g_thread_init_glib (gthread.c:165)
==3905== by 0x52B469C: g_thread_init (gthread-impl.c:355)
==3905== by 0x4C2CE73: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /usr/lib/libQtCore.so.4.5.0)
==3905==
==3905== LEAK SUMMARY:
==3905== definitely lost: 1,624 bytes in 15 blocks.
==3905== indirectly lost: 12,762 bytes in 435 blocks.
==3905== possibly lost: 129,913 bytes in 117 blocks.
==3905== still reachable: 1,492,515 bytes in 12,160 blocks.
==3905== suppressed: 1,396 bytes in 41 blocks.
==3905== Reachable blocks (those to which a pointer was found) are not shown.
==3905== To see them, rerun with: --leak-check=full --show-reachable=yes

MfG
Hundefutter

Beitrag von **Christian81** » 22. Juli 2009 17:16

Und warum korrigierst Du nicht erstmal Deine Fehler?

==3905== 1,576 (16 direct, 1,560 indirect) bytes in 1 blocks are definitely lost in loss record 190 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x8051B93: Todo_dialog::Todo_dialog(QWidget*) (todo_dialog.cpp:24)
==3905== by 0x805500B: main (main.cpp:9)

Den Dialog sollte man, wenn man ihn mit new anlegt auch wieder löschen.

Hundefutter · Beitrag von **Hundefutter** » 22. Juli 2009 23:46

Christian81 hat geschrieben:Und warum korrigierst Du nicht erstmal Deine Fehler?
==3905== 1,576 (16 direct, 1,560 indirect) bytes in 1 blocks are definitely lost in loss record 190 of 224
==3905== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==3905== by 0x8051B93: Todo_dialog::Todo_dialog(QWidget*) (todo_dialog.cpp:24)
==3905== by 0x805500B: main (main.cpp:9)
Den Dialog sollte man, wenn man ihn mit new anlegt auch wieder löschen.

Das mit new angelegt Objekt ist nicht der Dialog. Er gibt hier den Konstruktor des Dialoges an, da ich in dem ein QDomDocument mit new erstelle, welches ich jedoch im Destruktor des Dialoges wieder freigebe, da ich es die gesamte Laufzeit des Dialoges brauche.
Das QDomDocument ist eine private Klassenvariable, sollte man die nicht mit new erstellen?

MfG
Hundefutter

Beitrag von **Christian81** » 23. Juli 2009 06:38

Fakt ist das Du den Speicher nicht wieder freigibst - egal was Du behauptest.

Hundefutter · Beitrag von **Hundefutter** » 23. Juli 2009 10:08

Edit:

So, die ersten Probleme konnten beseitigt werden. Es lag daran, dass ich das QDomDocument erst neu erstellt und dann noch neu geladen habe, so hat er am Ende nicht alles wieder aufgeräumt.

Kann man eigentlich mit Valgrind testen, zu welchem Zeitpunkt mein Programm bestimmte Objekte wieder freigibt?
Der Destruktor der Items wird beim Löschen aufgerufen, das habe ich getestet. Jedoch zeigt mir der Systemmonitor immer noch die gleiche Speichermenge an, also wird laut diesem nix freigegeben. Wird der Speicher vielleicht von QT noch behalten und erst beim Beenden des Programms freigegeben?

Jetzt sieht der Speicherverbrauch laut Valgrind schon besser aus, nur leider sind im valgrind-report noch Ausgaben, die ich nicht zuordnen kann.
Habt ihr noch Tips, wie ich da mein Programm weiter verbessern kann?

Hier die aktuelle Ausgabe von Valgrind:

==7900== Memcheck, a memory error detector.
==7900== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==7900== Using LibVEX rev 1884, a library for dynamic binary translation.
==7900== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==7900== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==7900== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==7900== For more details, rerun with: -v

==7900==
==7900== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3388 from 7)
==7900== malloc/free: in use at exit: 2,754,397 bytes in 38,768 blocks.
==7900== malloc/free: 306,584 allocs, 267,816 frees, 37,683,091 bytes allocated.
==7900== For counts of detected errors, rerun with: -v
==7900== searching for pointers to 38,768 not-freed blocks.
==7900== checked 3,262,800 bytes.
==7900==
==7900== 148 (128 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 78 of 204
==7900== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==7900== by 0x519C9D6: FcPatternObjectInsertElt (fcpat.c:367)
==7900== by 0x519D3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==7900== by 0x519D4DE: FcPatternAppend (fcpat.c:991)
==7900== by 0x51A2FBE: FcEndElement (fcxml.c:2023)
==7900== by 0x5358EC3: (within /usr/lib/libexpat.so.1.5.2)
==7900== by 0x5359C10: (within /usr/lib/libexpat.so.1.5.2)
==7900== by 0x535B5EE: (within /usr/lib/libexpat.so.1.5.2)
==7900== by 0x535BCE6: (within /usr/lib/libexpat.so.1.5.2)
==7900== by 0x535268B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==7900== by 0x51A0EFD: FcConfigParseAndLoad (fcxml.c:2552)
==7900== by 0x51A1245: FcConfigParseAndLoad (fcxml.c:2438)
==7900==
==7900==
==7900== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 79 of 204
==7900== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==7900== by 0x4F2D548: (within /lib/tls/i686/cmov/libc-2.9.so)
==7900== by 0x4F2DE25: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.9.so)
==7900== by 0x5A40F5B: ???
==7900== by 0x5A41CBE: ???
==7900== by 0x4ED3811: getpwnam_r (in /lib/tls/i686/cmov/libc-2.9.so)
==7900== by 0x5131E71: g_get_any_init_do (gutils.c:1631)
==7900== by 0x5133924: g_get_home_dir (gutils.c:1782)
==7900== by 0x59AA524: ORBit_option_parse (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59B100F: CORBA_ORB_init (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x596A66E: gconf_orb_get (in /usr/lib/libgconf-2.so.4.1.5)
==7900== by 0x596A7FD: (within /usr/lib/libgconf-2.so.4.1.5)
==7900==
==7900==
==7900== 60 bytes in 1 blocks are possibly lost in loss record 90 of 204
==7900== at 0x40270FC: realloc (vg_replace_malloc.c:429)
==7900== by 0x5105169: g_realloc (gmem.c:170)
==7900== by 0x59B76B0: ORBit_realloc_tcval (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59BBC86: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x62F9B31: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62FDD83: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62FE1CD: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62B1D2C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==7900== by 0x62B1EDB: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==7900== by 0x616BA09: atk_bridge_init (bridge.c:217)
==7900== by 0x5BC2B4C: default_display_notify_cb (gtkmodules.c:417)
==7900== by 0x5064ABB: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)
==7900==
==7900==
==7900== 129 bytes in 8 blocks are possibly lost in loss record 112 of 204
==7900== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==7900== by 0x5105283: g_malloc (gmem.c:131)
==7900== by 0x59B77AF: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59B7478: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59BBAC4: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59BB92D: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x59BBC4E: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==7900== by 0x62F9B31: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62FDD83: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62FE1CD: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==7900== by 0x62B1D2C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==7900== by 0x62B1EDB: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==7900==
==7900==
==7900== 216 bytes in 1 blocks are definitely lost in loss record 123 of 204
==7900== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==7900== by 0x5227012: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==7900== by 0x5226E4F: _XimRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==7900== by 0x520B037: XRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==7900== by 0x4834096: (within /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x4832B90: QInputContextFactory::create(QString const&, QObject*) (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x4208BB4: QApplication::inputContext() const (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x4252BC7: QWidgetPrivate::inputContext() const (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x425651A: QWidget::inputContext() (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x420F9E8: QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x425961D: QWidget::setFocus(Qt::FocusReason) (in /usr/lib/libQtGui.so.4.5.0)
==7900== by 0x420FF93: QApplication::setActiveWindow(QWidget*) (in /usr/lib/libQtGui.so.4.5.0)
==7900==
==7900==
==7900== 4,480 (1,024 direct, 3,456 indirect) bytes in 3 blocks are definitely lost in loss record 177 of 204
==7900== at 0x40270FC: realloc (vg_replace_malloc.c:429)
==7900== by 0x519C951: FcPatternObjectInsertElt (fcpat.c:358)
==7900== by 0x519D3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==7900== by 0x519DA0B: FcPatternObjectAdd (fcpat.c:545)
==7900== by 0x519DA4F: FcPatternObjectAddBool (fcpat.c:691)
==7900== by 0x5191E25: FcDefaultSubstitute (fcdefault.c:136)
==7900== by 0x5ED8967: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:93)
==7900== by 0x5FED3D4: pango_fc_default_substitute (pangofc-fontmap.c:1586)
==7900== by 0x5FF05FE: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1640)
==7900== by 0x6027AD5: pango_font_map_load_fontset (pango-fontmap.c:136)
==7900== by 0x6025881: itemize_state_process_run (pango-context.c:1289)
==7900== by 0x6025E1E: pango_itemize_with_base_dir (pango-context.c:1467)
==7900==
==7900==
==7900== 140,040 bytes in 127 blocks are possibly lost in loss record 199 of 204
==7900== at 0x4024EFA: memalign (vg_replace_malloc.c:460)
==7900== by 0x4024FAE: posix_memalign (vg_replace_malloc.c:569)
==7900== by 0x511AA02: slab_allocator_alloc_chunk (gslice.c:1136)
==7900== by 0x511C1E2: g_slice_alloc (gslice.c:666)
==7900== by 0x50D589E: g_array_sized_new (garray.c:86)
==7900== by 0x50D59B6: g_array_new (garray.c:78)
==7900== by 0x5127A8B: g_static_private_set (gthread.c:451)
==7900== by 0x50E540F: g_get_filename_charsets (gconvert.c:1185)
==7900== by 0x50E5480: _g_convert_thread_init (gconvert.c:1290)
==7900== by 0x5127D2C: g_thread_init_glib (gthread.c:165)
==7900== by 0x52B469C: g_thread_init (gthread-impl.c:355)
==7900== by 0x4C2CE73: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /usr/lib/libQtCore.so.4.5.0)
==7900==
==7900== LEAK SUMMARY:
==7900== definitely lost: 1,404 bytes in 6 blocks.
==7900== indirectly lost: 3,596 bytes in 183 blocks.
==7900== possibly lost: 140,229 bytes in 136 blocks.
==7900== still reachable: 2,607,772 bytes in 38,402 blocks.
==7900== suppressed: 1,396 bytes in 41 blocks.
==7900== Reachable blocks (those to which a pointer was found) are not shown.
==7900== To see them, rerun with: --leak-check=full --show-reachable=yes

MfG
Hundefutter

Beitrag von **Christian81** » 26. Juli 2009 21:00

Alles was valgrind jetzt noch anzeigt kannst du nicht beeinflussen. Dein Programm ist also sauber.
Und wann ein Programm den Speicher wieder freigibt und wann Du es mit irgend einen Tool siehst sind zwei komplett unterschiedliche Dinge - wann der Speichermanger sich entscheidet Speicher wieder freizugeben kann man nicht beeinflussen.

Hundefutter · Beitrag von **Hundefutter** » 26. Juli 2009 23:18

Christian81 hat geschrieben:Alles was valgrind jetzt noch anzeigt kannst du nicht beeinflussen. Dein Programm ist also sauber.
Und wann ein Programm den Speicher wieder freigibt und wann Du es mit irgend einen Tool siehst sind zwei komplett unterschiedliche Dinge - wann der Speichermanger sich entscheidet Speicher wieder freizugeben kann man nicht beeinflussen.

Das hört sich doch schon einmal gut an

.

Vielen Dank für die aufklärenden Worte, werde auch weiterhin darauf achten, dass ich mit dem Speicher sauber umgehe.

Mit freundlichen Grüßen
Hundefutter