Нужна помощь в расследовании утечки памяти в сложном приложении TCL

Question

Я исследую возможную утечку памяти в приложении TCL.Это приложение использует несколько собственных разработанных DLL.Приложение порождает несколько экземпляров интерпретатора TCL.(Это использует TCL 8.4.13, я знаю, что оно старое, но и это приложения. LOL) Он работает на Windows ...

Из чтения в Интернете, я согласен, что утечка, скорее всего, в одномDLL.

Я думал (и начать), глядя на 3 способа, чтобы попытаться найти эту утечку.1. Использование команды «память», которая может быть включена в TCL.2. Использование VC (Visual C) профилировщика памяти.3. Использование VLD (Visual Leak Detector)

У каждого из них есть свои проблемы до сих пор.Команда памяти дает некоторую проблему, потому что мне нужно перестроить старый интерпретатор И все включенные в него пакеты.

VC дает мне в основном "внешний код" в качестве обратной трассировки ...

VLDЯ не смог заставить его работать.Это оставило меня с пустым файлом отчета.Я все еще исследую этот вопрос, поскольку смог включить его только в нашу сборку DLL, поскольку не собираю старый интерпретатор TCL и его пакеты.

Я немного новичок в TCL (некоторыемесяцев), поэтому любая помощь / предложение будет принята с благодарностью.

Также, если кто-то немного знает о том, как TCL управляет распределением памяти, было бы неплохо.Пока я не нашел много в Интернете.

Спасибо

Answer 1

Tcl имеет довольно сложный набор распределителей внутренней памяти, размещенных поверх базового распределителя системы.Целью наложения является снижение частоты, с которой требуется глобальная блокировка;На самом деле Tcl действительно хорош в этом, даже в многопоточных приложениях.Однако следствием этого является то, что Tcl на самом деле не выпускает неиспользуемые страницы обратно в операционную систему - он склонен полагать, что они могут понадобиться снова в будущем, и это предположение верно для большинства кодов приложений - и чтоможет выглядеть как утечка памяти.На самом деле это не утечка, но может выглядеть так.Существует также ряд глобальных кешей, которые не освобождают память, но стабилизируют объем используемой ими памяти на фиксированном уровне.

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

---

Я бы также отметил, что Tcl 8.4.13 сильно устарел.Даже 8.4.20 больше не поддерживается, но это по крайней мере, есть шанс строительства на современном оборудовании.Tcl 8.5 также находится в фазе долгосрочной поддержки;вероятно, будет только один его выпуск в будущем (если только мы не найдем серьезную ошибку, такую ​​как уязвимость в системе безопасности).8.6 является текущим выпуском рекомендуется-для-производства, и 8,7 и 9,0 находятся в стадии разработки.Хотя обновление кода с 8.4. * До 8.5 и более поздних версий может оказаться более трудоемким, чем вы готовы сделать, обновление до 8.4.20 определенно исправит некоторые ошибки (мне нужно прочитать подробности в примечаниях к выпуску, чтобы узнать, какие именно) идолжен быть достаточно простым.И если ваша проблема на самом деле является одной из этих исправленных ошибок, то обновление - это решение only , которое мы предоставим.