Как предсказать утечку памяти в программе Linux C / C ++?

0

Я пытаюсь предсказать утечку памяти в Linux-программе c++.

Программа является сетевым сервером, который обрабатывает много подпроцессов для обработки запроса.

Я могу получить RSS процесса после того, как он обработает один запрос, и я хочу, чтобы процесс был убит сам, если он обнаружил, что может быть утечка памяти.

Я могу заставить процесс убить себя, если он больше, чем настроенное значение (например, 1 ГБ), но это кажется слишком простым, и это значение также непросто настроить.

Я также могу заставить процесс убить себя, если RSS больше и больше для N раз (например, 100), но это тоже не подходит, если процесс кэширует некоторые данные.

Существуют ли алгоритмы прогнозирования утечки памяти?

Я искал его, но не могу найти его.

Благодарю.


Извините за то, что я не задал вопрос.

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

Ситуация такова:

Программа я worted - это RPC-инфраструктура, есть процесс отцов, который развивает множество подпроцессов.

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

Когда эти логические коды утечки памяти, подпроцесс будет убит os OOM Killer.

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

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

И если подпроцесс убивает сам себя, процесс отца приведет к откату другого подпроцесса для запуска логического кода.

Я могу получить память, занятую подпроцессом, после обработки одного запроса.

Таким образом, самый простой способ - проверить, занимает ли подпроцесс слишком много памяти, чем предварительно сконфигурированное значение (например, 1 ГБ), если оно есть, а затем заставить его убить себя.

Но этот алгоритм кажется слишком простым, и его значение не так просто настроить.

Итак, что я нахожу, является алгоритмом для прогнозирования того, что в процессе происходит утечка памяти.

благодаря

  • 5
    Предсказание: вероятность утечки памяти приближается к 1, когда программа на C ++ приближается к завершению.
  • 0
    Лучший способ - предотвратить утечки памяти, а не предсказать. Кроме того, если процесс убьет сам себя, какой смысл? Если произойдет нехватка памяти, он (скорее всего) потерпит крах, несмотря ни на что. ИЛИ , вы говорите о чем-то другом, а не о реальной утечке памяти.
Показать ещё 2 комментария
Теги:
algorithm
memory-leaks

4 ответа

5

Вы не можете предсказать утечки памяти (это, вероятно, может быть доказано эквивалентно проблеме остановки).

Вы можете измерить или измерить двоичный файл, в частности, с valgrind (который только скажет вам, произошло ли какое-то конкретное выполнение).

Вы также можете рассмотреть возможность использования консервативного сборщика мусора фирмы Boehm. Обычно это автоматически освобождает память (но нет гарантии, так как это консервативный сборщик мусора !).

1

Я пытаюсь предсказать утечку памяти в Linux-программе c++. [...] Есть ли какие-либо алгоритмы прогнозирования утечки памяти?

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

Это выглядит как проблема xy. Если у вас есть дочерние процессы с утечками памяти, правильным решением будет удаление утечек памяти из дочерних процессов. В противном случае вы можете наложить ограничение в своей системе (т.е. ни один дочерний процесс не будет потреблять более 350 МБ памяти). Этот предел, однако, никоим образом не связан с утечками памяти.

Чтобы обнаружить утечки памяти в процессе разработки, рассмотрите возможность использования специализированного инструмента (например, valgrind или BoundsChecker).

  • 1
    +1, если вы написали десять приложений, и у них у всех были утечки памяти, вы можете предсказать, что у вашего 11-го будут утечки памяти :-D
1

Без дальнейших ограничений нет. Программа может делать что угодно и, как результат, иметь какой-либо шаблон в своей памяти. Такие инструменты, как valgrind, могут обнаруживать утечки памяти, например, отслеживая распределение каждой памяти и замечая, когда есть часть выделенной памяти, которая недоступна. Но они, по сути, запускают программу в виртуальной машине или под отладчиком, что приводит к огромному снижению производительности, поэтому не решение для производства использует обнаружение утечки памяти.

Решение - это не утечка памяти, чтобы найти утечки памяти при разработке программного обеспечения. Там вы можете использовать инструменты, такие как valgrind, в сочетании с достаточным количеством тестовых примеров, чтобы поймать все утечки. Но лучше всего делать высококачественное программное обеспечение. Утечки памяти являются результатом либо плохой методологии, либо небрежной реализации.


Как практическое решение самой проблемы: не пытайтесь обнаружить утечки памяти. Просто перезапустите процесс, например, один раз в 24 часа, в то время, когда он вызывает наименьшее разрушение. Конечно, это немного "уродливое", оно поощряет просто игнорировать некоторые ошибки, если они должны быть исправлены, например. Это случай "уродливой реальности против принципов звуковой инженерии".

0

Один из способов борьбы с утечками памяти - реализовать подсчет ссылок. Идея состоит в том, чтобы иметь для каждого объекта или структуры число, указывающее на то, сколько указателей указывает на это, когда этот счетчик падает до 0, освобождая выделенную память. Это заставляет вас переосмыслить код, но он эффективен, когда несколько объектов указывают на другой объект и не могут предсказать, когда он станет бесполезным.

Если вы программируете в C++, вы можете попробовать увеличить библиотеки, у них есть реализация интеллектуальных указателей для подсчета ссылок.

http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/smart_ptr.htm

  • 0
    К вашему сведению, C ++ 11 также имеет удобные умные указатели, и на данный момент они, вероятно, намного лучше (для переносимости и т. Д.), Чем использование более старых версий Boost .

Ещё вопросы

Сообщество Overcoder
Наверх
Меню