LINUX.ORG.RU

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


0

0

Товарищи, подскажите как узнать, жрет мое приложение память или нет. В топ вижу постоянное увеличение задействованной памяти, но как можно отследить свое приложение?


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

Sphinx ★★☆☆ ()

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

staseg ★★★★★ ()
Ответ на: комментарий от Sphinx

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

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

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

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

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

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

golodranez ★★★★ ()

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?

da17 ()

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

vertexua ★★★★☆ ()
Ответ на: комментарий от da17

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

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

kemm ()

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

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

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

vertexua ★★★★☆ ()

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

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

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

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

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

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

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

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

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

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

mky ★★★★★ ()
Ответ на: комментарий от da17

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

unlce_sashko ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.