Собственно, сабж. Есть приложение, в процессе работы которого количество использованной памяти стабильно и неуклонно растет (платформа — Linux).
Задача осложняется тем, что утечек в обычном смысле нет: мемчекер по окончании работы не показывает потерянных указателей и утечек, т.е. по окончании все корректно освобождается. Прога обрабатывает файлы. То есть полный цикл алгоритма состоит из обработки одного файла, по окончании цикла количество использованной памяти должно равняться ее количеству до входа в цикл. Но, похоже, где-то забываю почистить какую-то динамическую структуры. Как такое отлавливать?
Здравствуйте, Аноним, Вы писали:
А>Собственно, сабж. Есть приложение, в процессе работы которого количество использованной памяти стабильно и неуклонно растет (платформа — Linux). А>Задача осложняется тем, что утечек в обычном смысле нет: мемчекер по окончании работы не показывает потерянных указателей и утечек, т.е. по окончании все корректно освобождается. Прога обрабатывает файлы. То есть полный цикл алгоритма состоит из обработки одного файла, по окончании цикла количество использованной памяти должно равняться ее количеству до входа в цикл. Но, похоже, где-то забываю почистить какую-то динамическую структуры. Как такое отлавливать?
Отключать (заменить на заглушки) функциональность по кусочкам, пока утечка не прекратится, потом начать добавлять обратно, пока не появится опять.
Здравствуйте, Аноним, Вы писали:
А>Собственно, сабж. Есть приложение, в процессе работы которого количество использованной памяти стабильно и неуклонно растет (платформа — Linux). А>Задача осложняется тем, что утечек в обычном смысле нет: мемчекер по окончании работы не показывает потерянных указателей и утечек, т.е. по окончании все корректно освобождается. Прога обрабатывает файлы. То есть полный цикл алгоритма состоит из обработки одного файла, по окончании цикла количество использованной памяти должно равняться ее количеству до входа в цикл. Но, похоже, где-то забываю почистить какую-то динамическую структуры. Как такое отлавливать?
В смысле, вся выделенная в цикле память освобождается, и Linux, типа, должен сделать sbrk назад?
А что по этому поводу думают библиотеки, которыми ты пользуешься, освобождают ли они свою память, в чем я сомневаюсь
Здравствуйте, wvoquine, Вы писали:
W>А что по этому поводу думают библиотеки, которыми ты пользуешься, освобождают ли они свою память, в чем я сомневаюсь
27.09.2013 10:22, Аноним 24 пишет:
> То есть > полный цикл алгоритма состоит из обработки одного файла, по окончании > цикла количество использованной памяти должно равняться ее количеству до > входа в цикл.
Вообще-то не должно и не будет.
А как искать, jazzer уже написал.
Здравствуйте, Аноним, Вы писали:
А>Как такое отлавливать?
Другой вариант — вместо отключения сделать scope-based memory usage/delta print. Вот таким образом:
{
{
MemUsageDelta foo("Part 1");
part1();
}
{
// Or as macro:
MEM_USAGE_DELTA("Part 2");
part2();
}
}
В конструкторе будет запоминаться текущее использование, а в деструкторе дельта пойдёт в log.
Для этого необходимо сделать свои operator new/new[], delete/delete[] (или что там у вас используется для аллокаций) + unordered_map для размеров — всего получается меньше ста строк.
Если есть такие проблемы, то можно сделать даже assert-like чтобы сразу их ловить:
Я такую феньку использовал для мониторинга использования памяти алгоритма который улучшал — для этих целей получается удобней чем, например, valgrind massif.
P.S. И в случае отключения кусочков, как посоветовали выше, и в случае мониторинга — не забываем про бинарный поиск.
27.09.2013 14:30, Evgeny.Panasyuk пишет:
> Для этого необходимо сделать свои operator new/new[], delete/delete[] > (или что там у вас используется для аллокаций) + unordered_map для > размеров — всего получается меньше ста строк.
Но там могут и малоки и другие запросы на выделение памяти.
Это все хорошо, если есть гарантия, что только new и delete. В более ни
менее сложных проектах на это закладываться опасно — время потратишь, а
выхлоп нулевой, имхо то, что написал jazzer универсальные и правильнее.
Здравствуйте, Vzhyk, Вы писали:
>> Для этого необходимо сделать свои operator new/new[], delete/delete[] >> (или что там у вас используется для аллокаций) + unordered_map для >> размеров — всего получается меньше ста строк. V>Но там могут и малоки и другие запросы на выделение памяти. V>Это все хорошо, если есть гарантия, что только new и delete.
Здравствуйте, Vzhyk, Вы писали:
V>27.09.2013 14:30, Evgeny.Panasyuk пишет:
V>Но там могут и малоки и другие запросы на выделение памяти. V>Это все хорошо, если есть гарантия, что только new и delete. В более ни V>менее сложных проектах на это закладываться опасно — время потратишь, а V>выхлоп нулевой, имхо то, что написал jazzer универсальные и правильнее.
Да, точно там буфер для чтения из файла увеличивается и фрагментирует память. Потом ее не удается по-старому на новой итерации упаковать приходится двигаться дальше...
А может и просто внутренняя фрагментация. Ясное дело, заставить сделать sbrk назад после цикла трудно, поэтому просто отменить всю ранее использованную память, пусть даже пользовательские структуры все похерены — нельзя. А в следующей итерации нам, допустим, потребуются другие размеры фрагментов...
Конечно же, мы тут не предполагаем, что там какие-нибудь уже ненужные векторы вроде как освобождаются, а зарезервированную память еще держат.
27.09.2013 15:10, wvoquine пишет:
> Да, точно там буфер для чтения из файла увеличивается и фрагментирует > память. Потом ее не удается по-старому на новой итерации упаковать > приходится двигаться дальше...
Это странно, если вы сами не запрашиваете читать, все большие блоки
памяти, причем так, чтобы вся цепочка "менеджеров памяти" это не с
амортизировала. Обычно в какой-то момент приложение выходит на некий
объем памяти и потребление находится около него (что-то по мелочи
освобождается, что-то захватывается).
Здравствуйте, Vzhyk, Вы писали:
V>Это странно, если вы сами не запрашиваете читать, все большие блоки V>памяти, причем так, чтобы вся цепочка "менеджеров памяти" это не с V>амортизировала. Обычно в какой-то момент приложение выходит на некий V>объем памяти и потребление находится около него (что-то по мелочи V>освобождается, что-то захватывается).
Да мы ведь и не знаем, в чем задача вообще состоит и даже на каком языке написана.
Но по описанию автора — в обычном смысле утечек нет, но он удивляется, что память все же растет от итерации к итерации.
Так вот интересно, насколько растет — есть там вообще тема для дискуссии, в первую очередь.
Во-вторых, насколько долго оно растет... Так то оно, может, и стабилизируется.
Здравствуйте, Аноним, Вы писали:
А>Собственно, сабж. Есть приложение, в процессе работы которого количество использованной памяти стабильно и неуклонно растет (платформа — Linux). А>Задача осложняется тем, что утечек в обычном смысле нет: мемчекер по окончании работы не показывает потерянных указателей и утечек, т.е. по окончании все корректно освобождается. Прога обрабатывает файлы. То есть полный цикл алгоритма состоит из обработки одного файла, по окончании цикла количество использованной памяти должно равняться ее количеству до входа в цикл. Но, похоже, где-то забываю почистить какую-то динамическую структуры. Как такое отлавливать?
Если у тебя в конце все освобождается, возможно, программа ведет учет выделенного как-то и потом удаляет, поэтому на выходе формально нет утечек,
а вот в каких-то частях код забывает о чем-то выделенном, и выделяет дальше снова и снова.
Поэтому надо смотреть отдельные участкие, встрой в места, где на входе и выходе должно быть одинаково, специальный код от tcmalloc, и скомпиляйся с ним.
Потом запусти работать. http://google-perftools.googlecode.com/svn/trunk/doc/heap_checker.html
Здравствуйте, Аноним, Вы писали:
А>Собственно, сабж. Есть приложение, в процессе работы которого количество использованной памяти стабильно и неуклонно растет (платформа — Linux). А>Задача осложняется тем, что утечек в обычном смысле нет: мемчекер по окончании работы не показывает потерянных указателей и утечек, т.е. по окончании все корректно освобождается. Прога обрабатывает файлы. То есть полный цикл алгоритма состоит из обработки одного файла, по окончании цикла количество использованной памяти должно равняться ее количеству до входа в цикл. Но, похоже, где-то забываю почистить какую-то динамическую структуры. Как такое отлавливать?
Можно запустить через dbx (или другой доступный отладчик):
>dbx <им программы>
dbx>runargs <параметры>
dbx>check -memuse или check -leaks или check -all
dbx>run
...
Возможно, результат наведет на какие-нибудь мысли.
