有没有办法强制“dlclose（）”释放内存？

Question

我的应用程序处理数千条消息，并使用dlopen / dlclose等在运行时调用共享库中的函数。

我一直在运行时分析内存，似乎（正如我所料）dlclose（）在关闭后不释放任何malloc内存。所以我有一个相当糟糕的内存泄漏....

问题是这些共享库是由其他人编写的，我不允许更改源代码。有没有办法解决？我想我可能调用一个“子进程”来处理消息，然后当它终止时，内存将消失在该子进程中....

还有其他想法吗？

感谢您的帮助

林顿

Answer 1

从您的问题中不清楚内存“泄漏”是由您加载的库分配的内存，还是由dlopen实现作为管理加载库的一部分。

如果它是由库分配，那么你要么滥用库而没有调用正确的函数来指示它释放它分配的内存，要么写得不好并分配（可能是第一次使用）它计划保留，重用和永不免费的数据。

如果通过dlopen 的实施分配，则没有错;这只是意味着dlopen决定它无法安全地卸载库，可能是因为仍然有一些对其符号的引用。这没有问题，因为同一个库的未来加载不会消耗更多内存，但会重用已经加载的副本。

现在，假设问题不在于您滥用库，所有问题都应该通过保持库打开而不是调用dlclose来修复，并自行重用/当你需要它时这样，即使库在你的背后分配了内存并且无法释放它，这只会发生一次（第一次加载库），而不是“N次”，因此它不是“内存泄漏”。

Answer 2

我相信它是由共享库分配的内存，你正在停留，你没有简单的方法来删除它（因为你不知道你的进程的哪些其他部分 - 例如哪些其他部分dlopen-ed库正在使用它）。如果您想了解更多信息，请阅读Garbage Collection或至少wikipage上的好书。作为对过程有用的内存是整个过程的全局属性，而不是特定库。

但是，某些库有关于内存使用的约定，并且可能为您提供清理内存和资源的功能。其他库不释放资源。 有些库使您能够为其调用的分配例程提供参数。

您可以考虑使用Boehm conservative garbage collector或使用valgrind之类的实用程序来追踪您的泄密。

祝你好运，因为你的问题没有一般解决方案。也许告诉我们更多关于你正在实施的实际库可能会有所帮助。

当然，还有不时重新启动过程的解决方法。

Answer 3

不，分配的任何内存都属于进程，而不是库。换句话说，dlclose无法知道您正在关闭的库分配了什么内存。任何行为良好的库都应提供清理功能，或者永远不会分配未返回给您的内存。并非所有的图书馆都表现良好......