Tracking down a memory leak in Ruby's EventMachine
blog.nelhage.com
Tracking down a memory leak in Ruby's EventMachine
1–10 of 33 posts
Re: Tracking down a memory leak in Ruby's EventMachine
#2I wish there were more posts like this.
Re: Tracking down a memory leak in Ruby's EventMachine
#3There are two things I really like about this walkthrough:
1. It shows how bugs can be something quite conceptually simple
2. It shows the value of logical, detective-like thinking in tracking these bugs.
Even as a programmer, I still think of bug-hunting as something requiring an encyclopedia knowledge of the trivial and arcane. Obviously, it looks easier in hindsight, but the OP does a great job of demonstrating how you can discover a much-overlooked flaw with the right deductive thinking (and experience with profiling tools)
Re: Tracking down a memory leak in Ruby's EventMachine
#4Like danso, I admire the detective-work here. I would like to point out, though, that XCode's Instruments utility has a fantastically useful "Leaks" mode that will identify leaked allocations, including a stack trace. It can attach to a running process and has a non-disastrous impact on performance, though like most such tools it's voracious for memory.
Other platforms likely have similar tools, though I have yet to stumble across one as easy to use.
Re: Tracking down a memory leak in Ruby's EventMachine
#5Like danso, I admire the detective-work here. I would like to point out, though, that XCode's Instruments utility has a fantastically useful "Leaks" mode that will identify leaked allocations, including a stack trace. It can attach to a running process and has a non-disastrous impact on performance, though like most such tools it's voracious for memory. Other platforms likely have similar tools, though I have yet to…
(author here) Yeah, there are a lot of such tools, and they can be invaluable. In my experience, though, if you're working with a large, complex system, including pieces like Ruby and OpenSSL which do some grody tricks internally, they'll flag lots of false positives and noise, and it takes a lot of work to get a development environment where they work well.
Also, we weren't yet sure whether this bug was reproducible in development/QA, or was only triggerable in production, so using techniques that worked directly on the running image was attractive.
Re: Tracking down a memory leak in Ruby's EventMachine
#6I wish there were more posts like this.
This is what I think of as the ideal HN - posts that are "How I Made X" or "How I Debugged Y" (or even "How Someone Else Made X", like the Amazon menu post, though the author ended up making their own implementation too).
No product announcement links, no Valley gossip rag links, no endless picking apart of every tiny Apple and Google thing.
What makes HN special are posts about making things. Everything else is just the same chatter all the other tech sites have.
Re: Tracking down a memory leak in Ruby's EventMachine
#7I wish there were more posts like this.
Me too. I wonder what would make for more posts like this.
Re: Tracking down a memory leak in Ruby's EventMachine
#8Like danso, I admire the detective-work here. I would like to point out, though, that XCode's Instruments utility has a fantastically useful "Leaks" mode that will identify leaked allocations, including a stack trace. It can attach to a running process and has a non-disastrous impact on performance, though like most such tools it's voracious for memory. Other platforms likely have similar tools, though I have yet to…
On Windows, there's kernel-mode support for similar allocation instrumentation, where every heap allocation can be tagged with a stacktrace.
I wrote a frontend: https://github.com/kevingadd/HeapProfiler but you can also just invoke it manually from the shell and then capture the state of the heap at your leisure.
Re: Tracking down a memory leak in Ruby's EventMachine
#9I noticed a same kind of leak in one of our apps and this post was more than worth of gold on how to hunt it down.