LINUX.ORG.RU
Форум — Development  

QT memory leak?


0

0 

Всем привет! Пишу под QT. Как-то недавно спрашивал тут, нужно ли мне
освобождать память объектов QT после вызова new. Сказали, что не надо.
Я и в хелпе это прочитал. Но непонятен один факт: после натравки 
valgrind'a на бинарник получил кучу mem leaks .. :( Приведу несколько
последних строчек лога:

==5261== 100992 bytes in 33 blocks are still reachable in loss record 699 of 700
==5261==    at 0x40026AB0: malloc (vg_replace_malloc.c:153)
==5261==    by 0x408B24E8: (within /usr/X11R6/lib/libX11.so.6.2)
==5261==    by 0x408B1A09: XLoadQueryFont (in /usr/X11R6/lib/libX11.so.6.2)
==5261==    by 0x434F1E33: load_fontset_data (in /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2)
==5261==
==5261==
==5261== 314832 bytes in 13118 blocks are still reachable in loss record 700 of 700
==5261==    at 0x40026BA4: __builtin_new (vg_replace_malloc.c:172)
==5261==    by 0x40521CA0: QListViewItem::setText(int, QString const &) (in /usr/lib/qt-3.0.4/lib/libqt-mt.so.3.0.4)
==5261==    by 0x4051F031: QListViewItem::QListViewItem(QListView *, QString, QString, QString, QString, QString, QString, QString, QString) (
==5261==    by 0x8062828: CSubtypeForm::FillSubtypeList(QString const &, bool) (src/csubtypeform.cpp:170)
==5261==
==5261== LEAK SUMMARY:
==5261==    definitely lost: 694 bytes in 45 blocks.
==5261==    possibly lost:   20700 bytes in 10 blocks.
==5261==    still reachable: 1380456 bytes in 36209 blocks.
==5261==         suppressed: 200 bytes in 1 blocks.
==5261==

Подскажите, что проверить для избежания leaks?? Может в деструкторе
вызывать всякие clear() и т.д. у членов класса, которые кстати тоже
являются объектами QT ?? Если у меня в начале столько ликов, что ж 
будет в конце, когда я допишу прогу? :)) Пусть кто-нибудь из тех, кто
юзает QT, потестит valgrind'ом свои проги на предмет --leak-check=yes
Интересен результат :) Вообщем, help ......

P.S. Наследуемые классы, созданные мной, имеют макрос Q_OBJECT
anonymous
← как и где грабли MySQL + C
Где лучше определить sys переменную KDEDIR →

это у тебя не утечки памяти

утечки памяти в valgrinde это definetly lost

а still reachable я так понимаю это память которая когда то освободится но valgrind не может понять где

------------------------------------ http://prog.org.ru/index.html Мастерская программиста

anonymous
()
Ответ на: комментарий от anonymous 

ОК, а как насчёт вот этого:

==5934== 4 bytes in 1 blocks are definitely lost in loss record 4 of 698
==5934==    at 0x40026BA4: __builtin_new (vg_replace_malloc.c:172)
==5934==    by 0x40525D4C: QListView::addColumn(QString const &, int) (in /usr/lib/qt-3.0.4/lib/libqt-mt.so.3.0.4)
==5934==    by 0x805FCBD: CEntityForm::FillEntityList(QString, bool) (src/centityform.cpp:152)
==5934==    by 0x80600E0: CEntityForm::Exec(void) (src/centityform.cpp:173)
==5934==
==5934==
==5934== 16 bytes in 1 blocks are definitely lost in loss record 70 of 698
==5934==    at 0x40026AB0: malloc (vg_replace_malloc.c:153)
==5934==    by 0x408CD219: (within /usr/X11R6/lib/libX11.so.6.2)
==5934==    by 0x408CEFE4: XrmGetStringDatabase (in /usr/X11R6/lib/libX11.so.6.2)
==5934==    by 0x408B4429: (within /usr/X11R6/lib/libX11.so.6.2)

или этого:

==5934== 216 bytes in 1 blocks are definitely lost in loss record 442 of 698
==5934==    at 0x40026AB0: malloc (vg_replace_malloc.c:153)
==5934==    by 0x43BF21F0: _XimOpenIM (in /usr/X11R6/lib/X11/locale/common/ximcp.so.2)
==5934==    by 0x408FF9D2: (within /usr/X11R6/lib/libX11.so.6.2)
==5934==    by 0x43BF1B54: _XimRegisterIMInstantiateCallback (in /usr/X11R6/lib/X11/locale/common/ximcp.so.2)
==5934==
==5934==
==5934== 216 bytes in 12 blocks are definitely lost in loss record 443 of 698
==5934==    at 0x40026AB0: malloc (vg_replace_malloc.c:153)
==5934==    by 0x409050B1: (within /usr/X11R6/lib/libX11.so.6.2)
==5934==    by 0x409057EC: _XlcLocaleDirName (in /usr/X11R6/lib/libX11.so.6.2)
==5934==    by 0x408FF858: _XlcDynamicLoad (in /usr/X11R6/lib/libX11.so.6.2)

???
Вот в первом абзаце: там лик после добавления колонки в листвью??
Как от него избавиться? или последние в 216 байт ... которые от меня
не зависят ....

anonymous
()
Ответ на: комментарий от anonymous

У меня примерно такое тоже постоянно. Я так думаю ошибка в глубине X и нам приходится на нее забить :(

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← как и где грабли MySQL + C
Development
Где лучше определить sys переменную KDEDIR →