Неудобный отчет по утечкам памяти в BDS2006.

← →
Gbp (2006-06-24 18:45) [0]

Неудобный отчет по утечкам памяти в BDS2006.

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

← →
jack128 © (2006-06-24 20:07) [1]

Gbp (24.06.06 18:45)
Как добавить в отчет информацию о том, в какой строке произошло выделение памяти и так далее?
это принципиально невозможно.

← →
Gbp (2006-06-24 20:10) [2]

так этот отчет в принципе неюзабелен? может из номера блока памяти можно вытянуть какую-нибудь информацию?

← →
jack128 © (2006-06-24 20:22) [3]

Gbp (24.06.06 20:10) [2]
так этот отчет в принципе неюзабелен?
почему неюзабилен? Мне, по крайней мере, помогает.
Gbp (24.06.06 20:10) [2]
может из номера блока памяти можно вытянуть какую-нибудь информацию?
вся возможная информация уже вытянута.

← →
Kolan © (2006-06-24 21:04) [4]

Используй MemProof

← →
Суслик © (2006-06-24 23:59) [5]

2avtor

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

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

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

← →
Ketmar © (2006-06-25 00:03) [6]

>jack128 © (24.06.06 20:22) [3]
право же, далеко не вся...

← →
jack128 © (2006-06-25 00:53) [7]

Ketmar © (25.06.06 0:03) [6]
например?

← →
Ketmar © (2006-06-25 01:31) [8]

да на любой. анализ памяти (post ли mortem, или live) может дать намного больше. как именно -- я полагаю, не мне вам рассказывать.

> [1] jack128 © (24.06.06 20:07)
> это принципиально невозможно.

Отчего же? Я не копался в принципе, но ведь менеджер памяти MemCheck это как-то ведь делает (не всегда разруливает верно, но "где-то рядом" всегда выбрасывает).

← →
_Seldon_ (2006-06-25 21:37) [10]

не знаю как в родном менеджере памяти bds2006 (который - суть покоцаный fastmm) - но в оригинальной версии fastmm можно включить FullDebugMode и тогда в логе для каждого лика будет указывацца CallStack с номерами строк и дамп первых 256 байт лика. правда при этом _очень_ страдает производительность менеджера.... но за всё надо платить :)

> _Seldon_ (25.06.06 21:37) [10]

> не знаю как в родном менеджере памяти bds2006 (который -
> суть покоцаный fastmm)

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

← →
_Seldon_ (2006-06-26 01:40) [12]

ну, значит скачай нормальный c fastmm.sf.net

Неудобный отчет по утечкам памяти в BDS2006. Найти похожие ветки