Memory leaks 需要帮助调查复杂TCL应用程序中的内存泄漏吗

我正在调查TCL应用程序中可能存在的内存泄漏。 此应用程序使用一些内部开发的DLL。 应用程序生成TCL解释器的多个实例。 （这是使用TCL 8.4.13，我知道这是旧的，但这也是应用程序。lol） 它正在Windows上运行

从网上阅读，我同意泄漏最有可能在一个DLL

我已经考虑（并开始）寻找3种方法来试图找到漏洞。 1.使用TCL中包含的“memory”命令。 2.使用VC（Visual C）内存分析器。 3.使用VLD（目视检漏仪）

到目前为止，他们每个人都有it问题。内存命令会产生一些问题，因为我需要重建旧的解释器和它附带的所有包

VC主要给我“外部代码”作为回溯

VLD I无法使其工作。它给我留下了一个空的报告文件。我仍在研究这个问题，因为我只能够在我们的DLL构建中包含它，因为我没有构建旧的TCL解释器及其包

我对TCL有点陌生（几个月），所以非常感谢您的帮助/建议

另外，如果有人对TCL如何管理其内存分配稍有了解，那就好了。到目前为止，我还没有在网上找到什么

---

多亏了

Tcl在基本系统分配器的基础上有一组相当复杂的内部内存分配器。分层的目标是减少需要全局锁的频率；Tcl实际上非常擅长这一点，即使在高度线程化的应用程序中也是如此。然而，这样做的结果是，Tcl并没有真正将未使用的页面释放回操作系统——它倾向于假设将来可能再次需要它们，这一假设在大多数应用程序代码中都是正确的——这看起来可能像内存泄漏。它实际上不是一个漏洞，但看起来像一个。还有一些全局缓存不会释放内存，但它们会将使用的内存量稳定在一个固定的水平

但用户代码完全有可能泄漏内存。在C级别，这通常可以通过错误地获取引用计数值来实现。在Tcl级别，最常见的原因是在全局变量（特别是全局数组）中存储大量内容，并且从不将其取消设置。这些不是Tcl本身的bug，而是代码中的bug。任何编程语言都可能有类似的问题

---

---

我还要指出，Tcl 8.4.13已经非常过时了。即使8.4.20也不再受支持，但这至少有机会在现代硬件上构建。Tcl 8.5也处于长期支持阶段；将来可能只有一个版本（除非我们发现一个严重的bug，比如安全漏洞）。8.6是当前推荐的生产版本，8.7和9.0正在开发中。虽然将代码从8.4.*升级到8.5及更高版本可能比您愿意做的工作更多，但升级到8.4.20肯定会修复一些bug（我需要阅读发行说明的详细信息才能知道是哪些bug），而且应该相当简单。如果您的问题实际上是其中一个修复错误，那么升级是我们提供的唯一解决方案。

如果没有更多关于发生了什么的详细信息，很难说得更多，而且您可能有很好的理由不能告诉我。我看到的行为是内存使用率随时间缓慢增加，但不是线性增加。它在启动时增加，然后随时间减少。我想说是对数曲线。所以，由于它是一名口译员，我的理论是这可能是正常的。请注意，这是一个长期运行（周）。我所看到的是，几个月后，情况趋于稳定。因为我不太了解TCL在底层是如何工作的，所以我不知道它是否有意义。