Show HN: Memleax – detects memory leak of a running process | Hacker News Reader

Show HN: Memleax – detects memory leak of a running process

github.com

42 pointshellowub9 comments

A short time before I met a memory leak problem in production environment. The process began memory leak after long-time running. So I need a tool to detect memory leak of a running process. I searched the web but didn't find one. Then I wrote such a tool myself. I wonder if the tool is useful for others. So I share it here, and wait for your advices.

Interesting idea, I'll give it a try tomorrow! Did you have any particular reason not to use GDB and its Python interface?

I guess that the trick is to set a breakpoint on *alloc/free, and inc/decrement a counter on breakpoint hit? I'll try to implement it in my own tool, but in Python!

I did not know GDB and its Python interface. I think it may be a better way. Expect for your tool!

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.

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.

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.

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.

Hm.. It'd be cool if I could run this on Heroku, though maybe that's a reason to switch to something like AWS?

Hm.. I do not know Heroku. Is there any problem that I could fix?

Reply on news.ycombinator.com