утечки памяти во время разработки

Question

Итак, я недавно заметил, что наш сервер разработки имеет устойчивую ~ 300 МБ из 4 ГБ памяти, оставшуюся после завершения разработки определенного проекта. Предполагая, что это связано с утечками памяти во время фазы разработки, эта память в конечном итоге освободится или потребует перезагрузки сервера. Существуют ли какие-либо инструменты, которые могут быть использованы для предотвращения этого в будущем (помимо очевидного, «не пишите код, создающий утечки памяти»)? Иногда они ненавидят ненадолго, и со временем я думаю, что они складываются, когда вы продолжаете тестировать свое приложение.

Answer 1

Не принимайте ничего, запустите профайлер памяти и посмотрите, что он делает.

Answer 2

В какой операционной системе вы работаете? Большинство операционных систем в эти дни очистят пропущенную память для процесса, когда процесс завершается. Возможно, что память, которую вы видите в использовании, фактически используется для кеша файловой системы. Это не о чем беспокоиться - ОС будет восстанавливать эту память, если это необходимо.

От: http://learnlinux.tsf.org.za/courses/build/internals/ch05.html

количество свободной памяти обозначается свободной команды включает в себя текущий размер буферного кэша в его расчета . Это вводит в заблуждение, так как количество свободной памяти указано часто будет очень низким, так как буфер кеш скоро заполняет большую часть пользовательской памяти. Не паникуйте. Приложения , вероятно, не переполняют вашу оперативную память; это просто буферный кеш, который принимает все свободное место. Подсчеты кэш-буфер как пространство памяти доступно для использования приложений (напомним, что он будет уменьшен по мере необходимости), так вычесть размер буфера кэша , чтобы увидеть реальное количество свободной памяти доступны для использования приложения

Answer 3

Запустите программу, используя исключительные valgrind на ящиках Linux x86.

Коммерческий эквивалент, Purify, доступен в Windows.

В этом анализе времени выполнения вашей программы будут сообщаться утечки памяти и другие ошибки, такие как переполнение буфера и унифицированные переменные.

Анализ статического кода - например, Lint и Coverity - также могут выявить утечки памяти и более серьезные ошибки.

---

Позволяет конкретно о том, что утечки памяти вызывают и как они нанесут вред вашей программе:

Если вы «утечка» памяти во время работы вашей программы есть риск того, что ваше приложение будет в конце концов исчерпать RAM и своп , или адресное пространство, доступное вашей программе (которое может быть меньше физической памяти) и привести к сбою следующего выделения. Подавляющее большинство программ не поймают эту ошибку, поскольку проверка ошибок сложнее, чем кажется. Большинство программ либо сбой, разыменовывая нулевой указатель, либо выйдет.

Answer 4

Лучше бороться с ними во время разработки,, потому что тогда легче идентифицировать ревизию, которая вводит утечку. Как вы, вероятно, видите сейчас, делать это после того, как это происходит очень, очень сложно.Ожидайте много отчетов при работе инструментов, которые я рекомендую ниже:

http://valgrind.org/

http://www.ibm.com/software/awdtools/purify/

http://directory.fsf.org/project/ElectricFence/

Я хотел бы предложить вам запустить этот инструмент, подавить большинство предупреждений о утечках, и затем фиксируйте их один за другим, удаляя супрессоры.

И затем убедитесь, что вы регулярно запускаете эти инструменты и быстро исправляете любые регрессии!

Answer 5

Конечно, очевидный ответ: «Не пишите код, который создает утечки памяти», и он действительный, потому что их можно очень затруднительно исправить, если у вас есть проблемы с подсчетом ссылок или сложный код, в котором трудно отслеживать срок службы памяти.

Для решения вашей текущей ситуации вы можете использовать такой инструмент, как DevPartner для Windows или Valgrind для Linux/Unix, оба из которых я считаю очень эффективными для отслеживания утечек памяти (а также других проблем таких как узкие места производительности).

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

И нет, я сомневаюсь, что память будет восстановлена ​​без перезапуска процесса, в котором работает ваш код.

Answer 6

Если это в Linux, проверьте вывод «free» и, в частности, проверьте количество «кэшированных» бара. Если ваша разработка включает в себя много дисковых операций ввода-вывода, она будет использовать ее для кеширования файлов, и вы увидите очень мало «доступных», но она по-прежнему существует, если это необходимо. Для всех практических целей рассмотрите бесплатный + кешированный как доступный.

«свободный» выход перегоняет из/Proc/MemInfo, и вы можете получить более подробную информацию о запущенном процессе в/Proc/$ PID/{карте, smaps}

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

Answer 7

Когда я учился в колледже, мы использовали Borland C++ Builder 6 IDE Он включал CodeGuard, который проверяет утечки памяти и другие проблемы, связанные с памятью. Я не уверен, что эта опция по-прежнему доступна в более новых версиях, но было бы странно, если бы новая версия имела меньше возможностей.

На linux, как упоминалось ранее, valgrind - хороший отладчик утечки памяти.