问题标签 [libumem]

说

solaris10 中的 ulib mem 仅显示 60 字节和 30 字节泄漏，为什么它不显示 128 字节也泄漏？

libumem 是否仅在 Solaris OS 或其他 OS 中可用

我想知道如何在 solaris 上使用 libumem。如果我按照http://www.unix.com/man-page/OpenSolaris/3malloc/umem_debug/并使用所有选项启动该过程，我将如何获得输出？

我可以获得结果的文本文件吗？

我在 HP-UX 上也使用了 wdb。这会在程序退出后生成一个文本文件，我可以稍后对其进行分析。我可以为 libumem 做同样的事情吗？

注意：这是一个远程调试，直到之后我才能访问系统。

我需要检查大量使用 JNI（C++ 代码）的 Java 应用程序中的内存泄漏。当我附加 libumem 时，进程在收到 SIGKILL（信号 9）后退出。

进程何时收到 SIGKILL？libumem 是如何引起的？

操作系统：Solaris 8。

我有一个在 Linux、Solaris 和 AIX 上运行的 C 应用程序。我使用了 Totalview 的 MemoryScape 之类的工具来追踪 Linux 上的内存泄漏，而且它是 100% 干净的。但是，我注意到 Solaris 上有一个小漏洞。

所以我一直在 Solaris 上使用“libumem”来尝试查找泄漏。

我的应用程序要么调用“用户出口”（通过子进程调用），要么不调用。

因此，如果我在没有用户退出的情况下运行应用程序（因此没有子进程调用），那么 libumem 可以 100% 工作......而且我仍然没有看到任何泄漏......

LD_PRELOAD=libumem.so UMEM_DEBUG=audit ./myapplication config.ini

但是当我打开用户出口调用以便主应用程序调用子进程时，我会在运行时由子进程将以下内容打印到 STDOUT：

ld.so.1：userexit_proxy：致命：libmapmalloc.so.1：没有这样的文件或目录

请注意，如果我不使用“libumem”，那么应用程序会 100% 运行......（仍然只是很小的内存泄漏）

现在我的应用程序是用 64 位编译的，我注意到 /usr/lib/libmapmalloc.so.1 是 32 位的，但这应该没什么区别......

知道如何在也调用子进程的应用程序上使用 libumem 吗？

注意：我也尝试将变量导出到整个环境，仍然没有运气

导出 LD_PRELOAD=libumem.so 导出 UMEM_DEBUG=审计

另外，如果我错了，请纠正我，但是如果子进程完成，那么该子进程中的任何“泄漏内存”都会自动释放，对吗？所以我可以假设 Solaris 上没有泄漏来自子进程调用？

在这方面的任何帮助将不胜感激

谢谢您的帮助

林顿

我有一个应用程序，我一直试图让“无内存泄漏”，我已经使用 Totalview 的 MemoryScape 在 Linux 上进行了可靠的测试，没有发现泄漏。我已将应用程序移植到 Solaris (SPARC) 并且我试图找到一个泄漏...

我在 Solaris 上使用过“LIBUMEM”，在我看来它也没有泄漏......

这是我的启动命令：

然后我立即检查了 Solaris 上的 PRSTAT 以查看启动内存使用情况：

然后我开始向应用程序发送数千条消息……随着时间的推移，PRSTAT 增长了……

就在我最终停止它之前：

现在有趣的部分是当我在这个应用程序上使用 LIBUMEM 时，它显示 48 MB 内存，如下所示：

如果我通过应用程序发送 10 条消息或 10000 条消息，“7 个超大泄漏，851968 字节”永远不会改变......它始终是“7 个超大泄漏，851968 字节”。这是否意味着应用程序没有根据“libumem”泄漏？

令人沮丧的是，在 Linux 上，内存保持不变，从不改变……但在 Solaris 上，我看到了这种缓慢但稳定的增长。

知道这意味着什么吗？我正确使用 libumem 吗？什么可能导致 PRSTAT 在这里显示内存增长？

对此的任何帮助将不胜感激......感谢一百万。

是否可以捕获 libumem 的 redzone 覆盖？我使用 libumem 分析内存损坏，发现某个块的 redzone 如下：

并且在此之后的所有块都以相同的方式交换。需要找出它可能在哪里/如何发生。

我有一个在 Solaris (SunOS m1001 5.10 sun4v sparc) 上运行的进程，并且正在监视使用的总虚拟内存。

定期运行 ps 表明 VSZ 随着时间的推移呈线性增长，跃迁 80kbytes，并且它一直在增长，直到达到 4GB 限制，此时它的地址空间不足，事情开始分崩离析。

我怀疑内存泄漏，并决定使用 pmap 进一步调查。但是 pmap 显示 VSZ 根本没有增长，而是保持稳定。此外，所有文件映射、共享内存映射和堆都保持相同的大小。

我的第一个问题是：为什么 ps 和 pmap 会为同一个进程产生不同的 VSZ？

我可以想象堆大小的计算方式不同（例如堆使用量与最高堆指针），因此开始考虑堆碎片的方向。然后，我使用 libumem 和 mdb 生成有关不同时间分配内存的详细报告，并注意到分配的内存绝对没有差异。

所以我的第二个问题是：找出导致 ps 报告的 VSZ 增长的原因的最佳方法是什么。