[jasone]

The fact that this can be used on a process even if you didn't plan at launch time to monitor memory usage is awesome. The main concern I'd have about using it in a production environment is performance impact. There may be no way around this (ptrace is expensive if gdb's impact on running applications is any indication), but the cost of backtracing all allocation sites is also very expensive. You may want to consider adding statistical sampling similar to what tcmalloc and jemalloc use for heap profiling, to reduce the performance impact and make it feasible to remain attached for longer periods of time.

[hellowub]

Because target progress's each memory allocation/free API invokes a TRAP, the performance influence depends on how often the target program calls memory APIs. For example, it impacts lightly to nginx with HTTP, while heavily with HTTPS, because OpenSSL calls malloc seriously.

Although performance influence is worthy of consideration, since `memleax` is run to attach the target progress only when you certain it is in memory leak, and stopped after real-time memory leak report, so it is not need to attach the target progress for long time.

-- I have added the above to README.md in new version.

Because you can stop memleax as soon as you get enough memory leak report, so the sampling idea will delay the stopping, which make the impact longer.

-- My English is poor, and hope I can make myself understood.

[cyphar]

You can attach GDB to running processes as well. Though I'm guessing you're making the comparison to valgrind. GDB could also be used to find memory leaks, but maybe not some of the more weird memory bugs.

[hellowub]

I did not know GDB well, and wrote this for fun. wazari972 is going to write a tool using GDB and its python interface. Let's expect for it.