Package: wnpp Severity: wishlist Owner: Nicholas D Steeves <nstee...@gmail.com>
Package name : memleax Version : 1.0.3 Upstream Author : WuBingzheng <wubingzh...@gmail.com> URL : https://github.com/WuBingzheng/memleax License : GPL-2 Programming Lang: C Description : debug a running process for memoy leaks without recompiling or restarting Memleax debugs a program for memory leaks by attaching to a running process, similarly to how gdb's does. It then hooks into the target process's invocation of memory allocation and free, and reports in real time the memory blocks that it identifies as memory leaks. The default expiration threshold is 10 seconds; however, you should always set this with the -e option according to your scenarios. . It is very convenient to use, and is suitable for production environments. There is no need to recompile the program that is being debugged and no need to restart the target process. Attach memleax to the target process, wait for the real-time memory leak report while it monitors the target program's memory allocation, and then kill memleax (e.g. sent it a SIGINT with Ctrl-C) to stop monitoring. . Memleax follows new threads, but not forked processes. If you want to debug multiple processes, just run multiple instances of memleax! . Differences from Valgrind: . * Valgrind starts the target process, while memleax attaches to on that is already running. * Valgrind reports memory leaks after target process ends, while memleax reports in real time. * Valgrind reports all unfreed memory, including program initialisation, while memleax reports only after attaching, skipping the init phase. * Valgrind runs the target process on its virtual CPU, which makes it slow. * Memleax hooks memory APIs, which may be less slow if the target process does not make use of many calls to memory APIs. * Valgrind debugs many kinds of memory bugs, while memleax is lightweight and only detects memory leaks. I discovered memleax because I needed to find something that could attach to a running process to debug memleaks. This ITP is contingent on memleax usefulness (yet to be established). If it proves to be useful to debug unanticipated memory leaks, then I believe it will be an asset to many Debian developers and bug reporters--particularly for hard to reproduce bugs. I'm 90% done the packaging (I just need to go over my work with my checklist), and I will need a sponsor. I plan to put the package into collab-maint, and I would welcome a co-maintainer who would like to work with upstream, if necessary, to make this program even better. Sincerely, Nicholas