11–20 of 33 posts
Earlier quoted context omitted.
Me too. I wonder what would make for more posts like this.
Who says there aren't already? Note that what's on the front page is just up-voted content. Tons of stuff (some quite good) slips through the cracks every day.
There 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 ho…
I have no doubt that the OP is good at reasoning logically, but the take-home lesson here is, if you want to be good at debugging, do a lot of debugging.
I wish there were more posts like this.
Me too. I wonder what would make for more posts like this.
Earlier quoted context omitted.
Me too. I wonder what would make for more posts like this.
Go here every day and upvote interesting articles after reading them. http://news.ycombinator.com/newest
Earlier quoted context omitted.
Go here every day and upvote interesting articles after reading them. http://news.ycombinator.com/newest
No, what I'm saying (cf my other comment in this thread) is that it's actually a supply problem.
In fewer words: It’s most likely a pointer."
As someone who has not stared at any core dump for more than about 2 seconds, I admire this level of skill.
There 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 ho…
Deduction is great, but what I read here was how much experience matters in debugging. You have to know what to look and test for to provide fodder for your reasoning capabilities, or else you're just shooting in the dark. The OP here had a plan informed by what I'm guessing are years of experience solving this kind of thing ("It's probably small objects. I should dump the core and look for repeating memory patterns.…
Summarizing the reasoning process:
1. The program's object space doesn't contain an absurd number of small objects, so inspect the core dump
2. 95% of the core dump is leaked objects, so a random sample should contain clues to the composition of the leaked objects.
3. A repeated pattern in every leaked object indicates a common pointer, i.e. a single type of object.
4. The signature helps find what file in the program is being referenced, which indicates that the pointer's object type is a BIO struct
5. This kind of leak isn't possible in straight Ruby. So between OpenSSL and EventMachine's C/C++ code, the latter is more likely to have something awry.
6. Search the EM code for BIO constructors
7. Check each constructor call to see if the BIO instance is ultimately freed
---
Steps 3 and 4 are the most arcane to me...I am pretty sure I do not know enough about memory to look at a hex signature and realize where in the address space it refers to, or even the significance of it.