Особый контроль утечки памяти

[visualman]

Я занимаюсь разработкой средства автоматизации тестирования. Сейчас я слежу за использованием памяти всем процессом тестируемой программы, и пришла в голову мысль, отслеживать память для каждого контрола на форме. Поскольку в программе достаточно много самописных (другими программерами фирмы) контролов, то такой подход думаю актуален. Подскажите, в каком направлении двигаться? Есть все hwnd, их классы, PID и всё, что можно было узнать о контролах. Всё, кроме занимаемой ими памяти.

[visualman]

А память подтекает точно ))))

[jangle]

IMHO не заниматься [Хакер]::Вырезано, а написать простейший контейнер в котором, по очереди протестить все контролы на предмет утечки памяти.

[Хакер]

Гм... Перехватывать все *Alloc, *Free-функции и следить за балансом. Нет?

jangle
Даже криптованный мат на этом форуме запрещён. А откровенно-матерное слово с заменённой первой буквой - тем более.

[visualman]

Вариант с контейнером отпадает. При переносе объекта из тестируемой проги в свой контейнер путём SetParent, прога ругается: Unexpected Error (вроде правильно написал)).

Allocate надо попробовать, но как я понимаю, это маршалинг, а тут я пока ламо.

[Хакер]

Не знаю каким образом маршалинг связан с функциями VirtualAlloc, VirtualFree, HeapAlloc, HeapFree, GlobalAlloc, GlobalFree и т.д.

[tyomitch]

Гм... Перехватывать все *Alloc, *Free-функции и следить за балансом. Нет?

Ага, попробуй перехватить сишные malloc и free из статично прилинкованного рантайма

[Хакер]

Сишные функции ведь всё равно являются переходниками к системным?

[tyomitch]

Нет, там свой менеджер кучи.
Стекается к Virtual* наравне с Heap*.
Global* и Local* сами стекаются к Heap*.

Ещё не забудь про CoTaskMem* и Sys*String, раз на то пошло.

[Хакер]

Хакер
Ну да. Сишный менеджер кучи юзает системные Virtual***-функции, а мы их можем перехватить. Нет?

[tyomitch]

Угу, любая куча в итоге стекается к Virtual*
Теперь предположим, что мы их перехватили.
Что нам это дало?

[Хакер]

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

[GSerg]

Вопрос не в том, чтобы сказать, есть ли утечка, а в том, где она.

[Хакер]

Какого формата ответ на вопрос "Где?" устроит автора. Автор ведь понимает, что номер строчки и имя файла-исходника получить нереально.

[tyomitch]

"В каком контроле"

[Хакер]

А контролы у него во внешних ocx-ах?

[visualman]

Автор отвечает: контролы в .ocx есть, но они так же есть в сорсах и мы, тестеры, не знаем, в каком варианте их прицепили к программе. Отдельное тестирование этих контролов не требуется, нужно тестить всю софтину.

[visualman]

Ещё раз озвучу задачу: в сторонней программе нужно отследить утечки памяти не для всего процесса, а ДЛЯ КАЖДОГО КОНТРОЛА отдельно. CopyMemory не спасёт положение?

Я так делал для выбора пункта в SysTreeView32 по её тексту. Копировал структуру информации о каждой записи в свою переменную, там проверял и если текст совпадал, то слал мессадж на выделение этой записи. Вот та структура, в которую я CopyMemory делал, может её размер считать? Хотя я очень не уверен, что это та память. И вообще такой подход помоему полный бред ))))

[GSerg]

Собственно, когда эта тема только появилась, я сразу подумал, что visualman, в своей обычной манере, проигнорировал http://bbs.vbstreets.ru/viewtopic.php?t=33830 и окунулся в детский сад, ничего не понимая в вопросе. Но всё же решил сначала убедиться в этом.

Убедился. tag_warning

Поскольку для тебя, visualman, он второй, тема закрывается. Третий будет для тебя последним.