分析网络应用程序中的资源泄漏(套接字处理程序等)

发布于 2024-10-18 13:32:10 字数 280 浏览 0 评论 0原文

对于内存泄漏,有许多工具可用,例如 valgrind,您可以使用它来找出泄漏的来源。对于 OpenGL 泄漏,有 glDEBugger,它对于此类事情非常有用。

有没有类似的网络编程工具?特别是在使用 Linux 套接字和管道时。

也许有一个 for-posix 工具可以测量程序正在使用多少 posix 资源(有多少个套接字,有多少个线程,有多少个互斥体等?)

另外,如果我错了,请纠正我,但是更高级的语言( java、python 等(而不是 c++)能够像处理内存管理一样处理这些资源管理吗?

For memory leaks, there are many tools available such as valgrind, which you can use to figure out where the leaks are coming from. For OpenGL leaks, there was glDEBugger, which was very useful for that kind of stuff.

Is there any similar tool for network programming? In particular, for when working with linux sockets and pipes.

Perhaps there's a for-posix tool that will measure how many posix resources a program is using (how many sockets, how many threads, how many mutexes etc?)

Also, correct me if I'm wrong, but would the higher level languages (java, python etc, as opposed to c++) be able to take care of these resource management as they do with their memory management?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

执着的年纪 2024-10-25 13:32:10

Valgrind 能够跟踪您感兴趣的一些资源:

  • 通过 memcheck

  • 通过 --track-fds=yes 的文件描述符 memcheck 选项

  • 通过 HelgrindDRD

生成的信息并不总是详细的,但它可能非常有帮助。

Valgrind has the ability to track a few of the resources you are interested in:

  • Memory via memcheck

  • File descriptors via the --track-fds=yes memcheck option

  • Threads and locks via Helgrind and DRD

The generated information is not always detailed, but it can be quite helpful.

素罗衫 2024-10-25 13:32:10

strace 和 lsof 可以(在一定程度上)帮助识别泄漏。几乎肯定有一些内存与套接字、管道等一起分配,您可以使用内存调试工具来跟踪这些内存,特别是如果您有包装资源分配器的自定义类,在这种情况下,添加一个将大量未使用的数据添加到这些类中,并在 memcheck 等的结果中查找这些巨大的数据块。

高级语言可能能够也可能无法管理这些资源。例如,如果您使用高级语言访问相同的低级函数,那么很可能资源没有受到管理。但是,如果资源被包装在可以进行垃圾收集的类中,那么是的,我认为垃圾收集也可以处理资源。

strace and lsof can be of (some) help in identifying leaks. There's almost definitely some memory allocated along with the sockets, pipes, etc. which you might be able to track with the memory-debugging tools, especially if you have custom classes wrapping the resource allocators, in which case it may be practical to add a giant chunk of unused data to those classes, and look for those giant chunks of data in the results of memcheck, etc.

Higher-level languages may or may not be able to manage these resources. For example, if you're accessing the same low-level functions in a high-level language, then most likely the resources aren't being managed. But if the resources are wrapped in classes that can be garbage-collected, then yes, I think the garbage collection can also take care of the resources.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文