Yes, this is true, so as I said, debugging looks easier in hindsight, especially someone else's hindsight :)
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.
The reasoning is reasonably well explained in the article, I think?
Noting there is an identical pointer in each object, assume this is a pointer to some kind of type definition struct. What will this have in it? There'll likely be a type name, some function pointers for standard operations, maybe a link to any more definitions, that kind of thing. This kind of arrangement is just something you do in C and C++. It's very common.
So take a look at what's at that address, under the assumption it's just a block of pointers. And then look at the first pointer (0x401 is obviously not a pointer). And in this case he got lucky, because it points to a suggestive string. (It could just as easily have pointed to another type definition, or something random. Though it's not uncommon for descriptors to have the name in the first field or two.)
Object type names are usually string literals so it's likely to point into the data segment of an EXE or DLL. (Maybe on Linux you can guess that from the address as well.) That's what the maps thing is all about - figuring out where the string might come from as a way of narrowing down the search.
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.