Утечки памяти.

Под валгриндом пускать.

Компилировать с -g, запускать под valgrind.

Я слоупок).

Матерь божия! Ну и бегемот этот valgrind. Ушел читать доки.... Гм..а утилита htop может сказать о расходе памяти? Смотрю при помощи ее за приложтением, как ело оно 0.9 м так и дальше ест.

Смотри на него месяца три, если ничего не трогать а потребление памяти вырастет - тут 50% что утечка

http://alexott.net/ru/writings/prog-checking/ - описания разных систем для отлова утечек и прочих ошибок

>Матерь божия! Ну и бегемот этот valgrind.

Не боись, там всё просто. man valgrind - за 5 минут разберёшся.

EAK SUMMARY: ==5295== definitely lost: 40 bytes in 1 blocks ==5295== indirectly lost: 120 bytes in 10 blocks ==5295== possibly lost: 3,807 bytes in 35 blocks ==5295== still reachable: 786,732 bytes in 17,979 blocks ==5295== suppressed: 0 bytes in 0 blocks Стоит ли бояться строчки indirectly lost?

Какие библиотеки вы используете в вашем приложении? Если больше и мощные, то valgrind будет на них ругаться в любом случае. Они могут запросто сами управлять памятью, почти сборкой мусора, такое он не любит.

> Стоит ли бояться строчки indirectly lost?

Либо оно само уйдёт при исправлении difinitely lost, либо перейдёт в категорию definitely lost. Т.е. можно забить, дальше будет понятно.

Сишные libcurl, libtds(MS SQL cервер) и libxml++. За указателями слежу внимательно. Боюсь, что могу не освобождать ресурсы после вызова сишных функций.

Да, кстати, например на Qt ругался жутко

Да, есть такое. И поэтому утечки памяти до сих пор ищу дедовскими методами.

А существует ли програмный способ. То есть в процессе работы мы вызываем какую-либо функции и запрашиваем объем памяти используемой программой? Кстати в случае утечек, сжираемая память будет принадлежать программе? Т.Е. является ли условие постоянного размера программы в течении работы необходимым и достаточным для отсутствия утечек. Прошу простить мою неопытность, я лишь только погружаюсь в этот мир борьбы за стабильную работу ПО.

> Да, кстати, например на Qt ругался жутко

Учитывая, что valgrind был придуман KDE'шниками... Дальше продолжать, или намёк понятен? 8))

>Кстати в случае утечек, сжираемая память будет принадлежать программе?

Да, программе. Если это не ошибка (утечка) в ядре ОС.

Вроде как да, но это при условии, что в течении работы задействуются все блоки кода. А так, скорее верно утверждение, что если при работе программы объем занимаемой ею памяти растёт, то в ней наверняка утечка памяти.

Последний абзац это ответ на вопрос «Т.Е. является ли условие постоянного размера программы...»

Есть грязный хак, описанный в книге Эккеля/Эллисона «Философия c++» Идея такова - переопределить операты new и delete, завести статическую карту памяти используемых указателей. По поводу отслеживания размера памяти работающего приложения - не совсем правильно. Допустим у тебя есть мелкий мемори лик, который обнаруживается только при каком-то действии. Ты сделал это действие один раз. Существенного прироста памяти ты не обнаружишь, но...если повторять это действие часто, то результат может оказаться совсем плачевным. Вот потому то и надо использовать тулы типо valgrind. Они позволяют произвести более качественный анализ мемори траблов. Плюс ищет эта штука не только мемори лики,но еще вроде и ABR и ABW.