Russian Qt Forum

У меня написан интерфейс программы (он же прототип), в нем порядка 25 классов, все включают Q_OBJECT и наследуются от QWidget или его разновидностей (QValidator в том числе). Ни одного delete в коде нет, также как нет дилитов в многочисленных примерах QT 5.3. Когда надо использовать delete ??? Как проверить, что в коде нет утечек памяти? В Qt Creator есть встроенный анализатор памяти, но при попытке его использования получаю:
Analyzing memory of C:\xxx\build-bc-Desktop_Qt_5_3_MinGW_32bit-Debug\debug\myApp.exe
Error: "valgrind" could not be started: No private key file given.
Analyzing finished.

1. valgrind не встроена в QtCreator, это внешняя(отдельная) программа. QtCreator обеспечивает ее запуск (если есть что запускать).
2. QObject и все его наследники при удалении удаляет все свои дочернии обьекты.

Прогони через cppCheck/ valgrind. Если не поможет, то просмотр кода и анализ :)

Под виндой valgrind не работает, поздравляю. Можно использовать платные штуки типа AQTime.

AddressSanitizer или Dr. Memory. Вот здесь видео о том как работает AddressSanitizer (https://tech.yandex.ru/events/science-seminars/Serebryanyi-30apr/talks/927/ (https://tech.yandex.ru/events/science-seminars/Serebryanyi-30apr/talks/927/))

Спасибо за советы! Вот, результат Dr Memory (точнее та часть, в кот. хотя бы, понятно проблемное место) :

~~Dr.M~~ Error #1: LEAK 80 direct bytes 0x15a30920-0x15a30970 + 0 indirect bytes
~~Dr.M~~ # 0 replace_operator_new                                        [d:\drmemory_package\common\alloc_replace.c:2449]
~~Dr.M~~ # 1 Qt5Guid.dll!QExplicitlySharedDataPointer<>::clone           [../../include/QtCore/../../src/corelib/tools/qshareddata.h:240]
~~Dr.M~~ # 2 Qt5Guid.dll!QExplicitlySharedDataPointer<>::detach_helper   [../../include/QtCore/../../src/corelib/tools/qshareddata.h:246]
~~Dr.M~~ # 3 Qt5Guid.dll!QExplicitlySharedDataPointer<>::detach          [../../include/QtCore/../../src/corelib/tools/qshareddata.h:145]
~~Dr.M~~ # 4 Qt5Guid.dll!QFont::detach                                   [text/qfont.cpp:661]
~~Dr.M~~ # 5 Qt5Guid.dll!QFont::setPointSize                             [text/qfont.cpp:968]
~~Dr.M~~ # 6 MainWindow::createTitle                                     [../myApp/mainwindow.cpp:227]
~~Dr.M~~ # 7 MainWindow::MainWindow                                      [../myApp/mainwindow.cpp:50]
~~Dr.M~~ # 8 main

код:
    QFont font = title->font();
    font.setPointSize(font.pointSize()*1.8 ) ;
    title->setFont(font);

~~Dr.M~~ Error #5: LEAK 184 direct bytes 0x15a64408-0x15a644c0 + 219 indirect bytes
~~Dr.M~~ # 0 replace_operator_new                 [d:\drmemory_package\common\alloc_replace.c:2449]
~~Dr.M~~ # 1 Qt5Cored.dll!QFile::QFile            [c:\work\build\qt5_workdir\w\s\qtbase\src\corelib/io/qfile.cpp:253]
~~Dr.M~~ # 2 MainWindow::MainWindow               [../myApp/mainwindow.cpp:38]
~~Dr.M~~ # 3 main 

код:
    QFile file(":/qss/origin.qss");
    file.open(QFile::ReadOnly);
    QString styleSheet = QLatin1String(file.readAll());
    setStyleSheet(styleSheet);
    file.close();

И что с ним не так? 1й кусок кода (с фонтом)  скопирован из примера кьют калькулятор- нет там никакого дилита  ???

у Qt свой менеджер памяти, поэтому dr. Memory и Valgrind часто необоснованно ругаются на утечку памяти. http://ubuntuforums.org/showthread.php?t=896913 (http://ubuntuforums.org/showthread.php?t=896913)

Первый раз об этом слышу. Если бы был свой менеджер памяти, valgrind бы ничего не показывал, так как он перехватывает функции malloc, free.

Ну может в каких-то редких случаях используются свои аллокаторы. Но valgrind, по идее, их должен вообще не видеть.

Вероятно в Qt текут синглтоны, т.к. на освобождение их памяти можно забить.

Вот здесь http://developer.nokia.com/community/wiki/Using_valgrind_with_Qt_Creator (http://developer.nokia.com/community/wiki/Using_valgrind_with_Qt_Creator) написано, что не надо обращать внимание на ошибки в glibc или Qt. Сайт нокиевский, можно доверять тому, что там написано. Там так же сказано, что при использовании валгринда можно использовать "suppression files", который позволяет убрать из вывода ложные срабатывания. Про dr. memory я подобного не нашел, но думаю что дела там обстоят так же.

??? Тоже никогда об этом не слыхал. Поясните что имелось ввиду

Ну а "свой менеджер" тут причем? Про него там ничего не увидел

На OSX с valgrind неважно (на большом проекте тормоза невыносимы), зато есть прекрасный Leaks (Instruments)

Для валгринда есть фильтры, которые отключают показ утечек в Кьюте.

Здесь (сайт нокии) (http://developer.nokia.com/community/wiki/Using_valgrind_with_Qt_Creator) ни чего про менеджер памяти не говориться, а говориться на форуме (http://ubuntuforums.org/showthread.php?t=896913). Сам про менеджер Qt не слышал/сталкивался. Знаю что в Qt батя за своими детьми сам следит и сам, когда надо, их удаляет.

и где там про менеджер памяти написано?
вот об этом там и идет речь

Цитата с форума:
"Valgrind results are usually wrong when you are testing a program that uses QT (and GTK too), because the way that QT manages the memory."

Хватит толочь воду в ступе. Valgrind не может правильно оценить утечки в Qt без дополнительных телодвижений.
И да, менеджер памяти в Qt есть, упрощенный - так называемая система родительского контроля :D

Ну если с Valgrind'ом понятно что делать, то с Dr. Memory хз. Валгринда под виндой нет.

Откидывать явные ложняки :)

PS а если честно - проще именно то, что я советовал :) CppCheck + просмотр всех мест где динамически создаются объекты. Qt делает всё на твёрдую пятерочку, значит проблема именно в вашем распределении памяти :)

"И тут Остапа понесло"  :)

Понял, о разных понятиях мы тут  размышляем. Для меня менеджер памяти - это реализация, стоящая за malloc/new. А автоматическое управление временем жизни объекта на базе родительских отношений - это, на мой взгляд, не менеджер памяти.

Ну, в общем, даже и родительские отношения тут не причем, если не удалить самого верхнего родителя, то память потечет как миленькая. Так что valgrind все правильно ловит, а Кутешники просто чинить ленятся, т.к. течет оно в основном в синглтонах, т.е. не критично, приложение всё равно сдыхает, зачем еще дополнительно память освобождать :)

В данном случае "на мой взгляд" можно смело отбросить. Если я в деструкторе делаю delete др объекта - разве это менеджер? :) Менеджер по меньшей мере должен знать сколько памяти приложение уже заняло, автоматычно освободить часть ресурсов если обнаружена нехватка и.т.п. Там мало не покажется, причем 64 bit ничего не меняют. А называть parent-child менеджером памяти - ну, мягко говоря "не очень грамотно"  :)

Неграмотно говорить, что этот механизм им не является :D

Менеджер памяти это не класс, не механизм, а абстрактное понятие :)

Менеджер управляет памятью. Это его главное предназначение. И управление в максимальном упрощении - это создание и корректное удаление.
Система Родитель-Ребёнок создаёт и удаляет всё корректно :)

Результат Cppcheck, действительно, выглядит повеселее. Одну ошибку находит:
"C-style pointer casting detected. C++ offers four different kinds of casts as replacements: static_cast, const_cast, dynamic_cast and reinterpret_cast. A
C-style cast could evaluate to any of those automatically, thus it is considered safer if the programmer explicitly states which kind of cast is expected."
win = (MainWindow *) QApplication::activeWindow();

Аха :)

Ну как бы этот кусок у вас неверно сработает, если активным будет QWidget :) Потому надо использовать qobject_cast и проверять результат на 0 после :)

Перечитал тему - самый простой способ проверки утечки памяти - запуск программы и работа с ней в течении некоторого времени с фиксацией занимаемой памяти :)

Данный способ поможет узнать, есть ли утечки или нет. Но Valgrind, Dr. Memory и прочие позволяют узнать кто течет и как.