memleak: Resolve stacks with a StackTrace table
authorVicent Marti <tanoku@gmail.com>
Fri, 25 Mar 2016 16:14:34 +0000 (17:14 +0100)
committerVicent Marti <tanoku@gmail.com>
Sat, 26 Mar 2016 00:29:24 +0000 (01:29 +0100)
commite25ae03eaa966a35c55f185a9b34c1a01115b5f2
treed79ecda133c250aaca4d716de6a35317dbd9e2ab
parent478636be18f574e392dfe3a87c5a693c0f0bf32f
memleak: Resolve stacks with a StackTrace table

Instead of manually walking the (kernel) stack inside the eBPF code,
create a `BPF_STACK_TRACE` table and store the stack IDs in the alloc
info struct.

This greatly simplifies the leak detection code: instead of storing the
full stack trace as a string to de-duplicate the allocation point for
the different allocations, we can store the `stack_id`. Since we're
creating stack IDs with `BPF_F_REUSE_STACKID`, the kernel will take care
of deduplication for us.

Additionally, the `StackDecoder` class has been specialized into a
`UStackDecoder` and `KStackDecoder` (for userland and kernel stacks,
respectively). This lets us pass the decode class directly to
`stack_traces.walk()` to automate symbol resolution.

A new class, `Allocation` has been created to encapsulate what
previously was a 2-element tuple of `(count, size)`. This
man/man8/memleak.8
tools/memleak.py
tools/old/memleak.py [new file with mode: 0755]