Мне необходимо протестировать ряд классов в .net на предмет наличия утечек памяти. Для этого надо создать несколько автоматизированных тестов, которые будут гонять каждый класс по их определенным методам и определять где происходят утечки памяти. При этом предполагается, что разработчик этих классов будет работать независимо от тестов. Теперь вопрос: если у кого-нить соображения, идеи, исходники по поводу того, как это реализовать в .net и можно ли это реализовать в .net? Или надо использовать com? Или есть какая-нить удобная подходящая софтина для этого?
Спасибо.
Re: Автоматизированные тесты утечек памяти
От:
Аноним
Дата:
02.03.05 10:34
Оценка:
Здравствуйте, smlalx, Вы писали:
S>Привет всем,
S>Мне необходимо протестировать ряд классов в .net на предмет наличия утечек памяти. Для этого надо создать несколько автоматизированных тестов, которые будут гонять каждый класс по их определенным методам и определять где происходят утечки памяти. При этом предполагается, что разработчик этих классов будет работать независимо от тестов. Теперь вопрос: если у кого-нить соображения, идеи, исходники по поводу того, как это реализовать в .net и можно ли это реализовать в .net? Или надо использовать com? Или есть какая-нить удобная подходящая софтина для этого?
Ничего не понимаю. Там же сборка мусора есть.
Какие утечки памяти?
Здравствуйте, Аноним, Вы писали:
А>Ничего не понимаю. Там же сборка мусора есть. А>Какие утечки памяти?
Подразумевается unintentional object/reference retention. Например, когда в коллекцию элементы постоянно добавляются и не удаляются. Сборщик мусора не вправе такие объекты удалить несмотря на то, что они (эти объекты в коллекции) по логике программы больше никогда использоваться не будут.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, smlalx, Вы писали:
S>>Привет всем,
S>>Мне необходимо протестировать ряд классов в .net на предмет наличия утечек памяти. Для этого надо создать несколько автоматизированных тестов, которые будут гонять каждый класс по их определенным методам и определять где происходят утечки памяти. При этом предполагается, что разработчик этих классов будет работать независимо от тестов. Теперь вопрос: если у кого-нить соображения, идеи, исходники по поводу того, как это реализовать в .net и можно ли это реализовать в .net? Или надо использовать com? Или есть какая-нить удобная подходящая софтина для этого?
А>Ничего не понимаю. Там же сборка мусора есть. А>Какие утечки памяти?
А>Ну а вообще смотри на BoundsChecker
Честно говоря, я сам не очень понимаю насчет утечек памяти. Читал статьи про .net, насколько все круто сделано и т.п., типа никаких утечек памяти так как есть gc. Но как работает этот gc на самом деле мне не известно, известно только то, что при его использовании все равно происходят эти самые утечки, достаточно посоздавать несколько десятков экземпляров форм (и др. классов) и посмотреть в task manager, как растет объем используемой памяти.
Re[3]: Автоматизированные тесты утечек памяти
От:
Аноним
Дата:
02.03.05 10:58
Оценка:
Здравствуйте, dshe, Вы писали:
D>Здравствуйте, Аноним, Вы писали:
А>>Ничего не понимаю. Там же сборка мусора есть. А>>Какие утечки памяти?
D>Подразумевается unintentional object/reference retention. Например, когда в коллекцию элементы постоянно добавляются и не удаляются. Сборщик мусора не вправе такие объекты удалить несмотря на то, что они (эти объекты в коллекции) по логике программы больше никогда использоваться не будут.
Ну это не утечки памяти в общепринятом смысле.
Это разве можно выловить автоматически как нормальные утечки в С++?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, dshe, Вы писали:
D>>Здравствуйте, Аноним, Вы писали:
А>>>Ничего не понимаю. Там же сборка мусора есть. А>>>Какие утечки памяти?
D>>Подразумевается unintentional object/reference retention. Например, когда в коллекцию элементы постоянно добавляются и не удаляются. Сборщик мусора не вправе такие объекты удалить несмотря на то, что они (эти объекты в коллекции) по логике программы больше никогда использоваться не будут.
А>Ну это не утечки памяти в общепринятом смысле.
Memory leak -- это вполне естественный термин даже для платформ с GC типа Java и .NET. Это скорее симптом, а не диагноз.
А>Это разве можно выловить автоматически как нормальные утечки в С++?
Они отлавливаются при помощи профайлеров. И в принципе, наверное, можно выделить определенные эвристики для этого. По-моему OptimizeIt что-то такое позволяет.
S>Честно говоря, я сам не очень понимаю насчет утечек памяти. Читал статьи про .net, насколько все круто сделано и т.п., типа никаких утечек памяти так как есть gc. Но как работает этот gc на самом деле мне не известно, известно только то, что при его использовании все равно происходят эти самые утечки, достаточно посоздавать несколько десятков экземпляров форм (и др. классов) и посмотреть в task manager, как растет объем используемой памяти.
Мда, пора это заносить в FAQ. Наряду с вопросом , как мне запустить программу без фрэймворка.
Поищите по форумам. Данный вопрос уже несколько раз подымался. Если кратко то — не смотрите в таск манагер.
Где-то между собакой и богом.
Re[4]: Автоматизированные тесты утечек памяти
От:
Аноним
Дата:
02.03.05 12:36
Оценка:
Здравствуйте, Dog, Вы писали:
S>>Честно говоря, я сам не очень понимаю насчет утечек памяти. Читал статьи про .net, насколько все круто сделано и т.п., типа никаких утечек памяти так как есть gc. Но как работает этот gc на самом деле мне не известно, известно только то, что при его использовании все равно происходят эти самые утечки, достаточно посоздавать несколько десятков экземпляров форм (и др. классов) и посмотреть в task manager, как растет объем используемой памяти. Dog>Мда, пора это заносить в FAQ. Наряду с вопросом , как мне запустить программу без фрэймворка. Dog>Поищите по форумам. Данный вопрос уже несколько раз подымался. Если кратко то — не смотрите в таск манагер.
В данном контексте "таск манагер" — это всего лишь пример, грубая оценка (при размере используемой памяти в 500 мб для довольно простенькой программки на .net).
Здравствуйте, <Аноним>, Вы писали:
Dog>>Поищите по форумам. Данный вопрос уже несколько раз подымался. Если кратко то — не смотрите в таск манагер. А>В данном контексте "таск манагер" — это всего лишь пример, грубая оценка (при размере используемой памяти в 500 мб для довольно простенькой программки на .net).
все равно не смотрите. Или сначала minimize/maximize а потом смотрите
Сборщик мусора ничем не поможет, если в компоненте есть ошибки. А если это чужой компонент, или, не дай бог, запчасть от framework'а, то начинаются очень интересные танцы с бубнами. Если ошибка в своем коде, то да, профайлеры её скорее всего быстро обнаружат. А BC может и прозевать. Он думает так: "при закрытии главной формы память высвобождается? Вот и хорошо. Значит так и должно быть", — а нет, это утечка.