Есть приложение в котором наблюдается нечто похожее на "утечки памяти"
— примерно через месяц работы сжираются все 4Гб виртуальной памяти, и оно умирает.
ОС — win2008 x64, приложение x32.
Перекомпилировать приложение нельзя (нет полных исходников), зато можно перехватить new/delete
В приложении постоянно зачем-то выделяется\удаляется память, и снижать производительность приложения очень нежелательно.
Зато в начале работы приложения есть много свободной памяти, и можно зарезервировать ~2Гб.
При запуске на тестовой машине, после завершения приложения вся память освобождается. Впрочем возможности полноценно нагрузить его на тестовой машине — нету.
Итак вопрос — что делать?
(Еще раз отмечу, что ОС — винда64, что способ поиска утечки не должен заметно влиять на производительность программы)
Здравствуйте, Abyx, Вы писали:
A>Есть приложение в котором наблюдается нечто похожее на "утечки памяти" A>- примерно через месяц работы сжираются все 4Гб виртуальной памяти, и оно умирает. A>ОС — win2008 x64, приложение x32.
A>Перекомпилировать приложение нельзя (нет полных исходников), зато можно перехватить new/delete A>В приложении постоянно зачем-то выделяется\удаляется память, и снижать производительность приложения очень нежелательно. A>Зато в начале работы приложения есть много свободной памяти, и можно зарезервировать ~2Гб.
A>При запуске на тестовой машине, после завершения приложения вся память освобождается. Впрочем возможности полноценно нагрузить его на тестовой машине — нету.
A>Итак вопрос — что делать?
A>(Еще раз отмечу, что ОС — винда64, что способ поиска утечки не должен заметно влиять на производительность программы)
исходников нет — делать особо нечего. Напиши сервис, кот.раз в полмесяца перезапускает это приложение
Здравствуйте, Abyx, Вы писали:
A>Есть приложение в котором наблюдается нечто похожее на "утечки памяти" A>- примерно через месяц работы сжираются все 4Гб виртуальной памяти, и оно умирает. A>ОС — win2008 x64, приложение x32.
Здравствуйте, Abyx, Вы писали:
A>фикс утечки — не проблема, если она будет найдена. Да, без исходников, и да, без перекомпиляции.
не очень ясно что значит "найти утечку" в вашем случае, не ясно почему вопрос в C\C++ прикладных вопросах
неясно, речь об утечке или распухании памяти (то есть накапливание памяти, которую при выходе вообще-то приложение удалит, как показывают ваши тесты)
неясно какими сущностями вы будете оперировать во время "устранения утечек" : то ли бинари на уровне asm хочить, то ли попросите автора по емейлу пофиксить там-то и там-то, то ли в какой-то форме исходники у вас есть и вы сами зафиксите\перекомпилируете бинари
вам не дают конкретных советов, потому что вы недостаточно полно осветили задачу
по имеющимся данным сформулировали лишь несколько советов:
1) если ящик черный, то внешней программкой следить за потребелением памяти\делать еже(дневные\недельные) рестарты
2) если есть белые пятна, то перекомпилировать с vld, смотреть его репорты по выделениям
3) проинструментировать прогу с помощью purify, valgrind, boundchecker, aqtime, etc, если есть .pdb
на уровне ассемблера тяжело определить понятие утечки, гораздо проще это сделать на уровне более высокоуровневого языка типа C++
Здравствуйте, uzhas, Вы писали:
U>не очень ясно что значит "найти утечку" в вашем случае, не ясно почему вопрос в C\C++ прикладных вопросах
в С++ потому что ожидается решение на С++
U>неясно, речь об утечке или распухании памяти (то есть накапливание памяти, которую при выходе вообще-то приложение удалит, как показывают ваши тесты)
я еще не уверен, но все же это больше похоже на утечку, чем на кеширование или фрагментацию
U>неясно какими сущностями вы будете оперировать во время "устранения утечек" : то ли бинари на уровне asm хочить, то ли попросите автора по емейлу пофиксить там-то и там-то, то ли в какой-то форме исходники у вас есть и вы сами зафиксите\перекомпилируете бинари
пропатчу бинарник
U>по имеющимся данным сформулировали лишь несколько советов: U>1) если ящик черный, то внешней программкой следить за потребелением памяти\делать еже(дневные\недельные) рестарты
рестарты очень затратны — получается большое время простоя, потому нежелательны
U>2) если есть белые пятна, то перекомпилировать с vld, смотреть его репорты по выделениям
перекомпилировать весь код не получится.
можно рассматривать неперекомпилируюмую часть как, скажем DLL к которой нет исходников.
U>3) проинструментировать прогу с помощью purify, valgrind, boundchecker, aqtime, etc, если есть .pdb
pdb нет.
и вообще, это инструментирование не снизит производительность программы раз в 100 ?
==========
вообще можно сделать следующее.
запоминать откуда была выделена память (например стек вызовов глубиной 3-4),
— тогда после завершения программы будет список повисших указателей.
только совершенно непонятно как это поможет определить где именно они утекли
есть подозрение что память утекает изза того что я где-то сломал SEH и при исключениях не вызывается какой-то деструктор.
Здравствуйте, Abyx, Вы писали:
A>есть подозрение что память утекает изза того что я где-то сломал SEH и при исключениях не вызывается какой-то деструктор.
память — не единственный ресурс, который может утекать при поломке деструкторов
опять же, даже если иметь список кусков памяти, которые утекли, неясно когда их можно удалять (если мы это планируем делать снаружи), ведь их можно удалять тогда, когда точно соотвествтующий (глючный) деструктор точно отработал. то есть без знаний высокоуровневых параметров программы это нереально сделать
можно по таймаутам удалять, но опять же дело опасное =) а если в этой памяти лежат объекты с нетривиальными деструкторами, то и логика могла сломаться
так что если у вас идея на тему сломаных деструкторов, то попробуйте ее развить и починить. тогда грязных фиксов удастся избежать
успехов
