Bug#883075: ITP: memleax -- debug a running process for memoy leaks without recompiling or restarting

[Nicholas D Steeves <nsteeves@gmail.com>]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves <nsteeves@gmail.com>

Package name    : memleax
Version         : 1.0.3
Upstream Author : WuBingzheng <wubingzheng@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