Add a method to trace call paths (for create/ref/deref)

[Lekensteyn]

(based on PR #7, branch https://github.com/Lekensteyn/gobject-list/tree/fix-libunwind)

Useful to debug reference count leaks where a lot objects are still
held just because a single object was not released elsewhere...

Totally not optimized and slows down a lot, but it gets the job done.

I used this to track down a very annoying reference count leak in UPower
which slows made it harder to analyze real issues.

Colored example at https://lekensteyn.nl/gobject-list-upower.html

Uncolored example for a very simple program which calls just g_cancellable_new() and fails to unref it:

$ GOBJECT_LIST_DISPLAY=all LD_PRELOAD=./libgobject-list.so ./a.out
 ++ Created object 0x212b610, GCancellable
#0  g_object_new + [0x00000161]
#1  main + [0x00000014]
#2  __libc_start_main + [0x000000f0]
#3  _start + [0x00000029]
Error getting frame: unspecified (general) error (1)
Leak!

Still Alive:
 - 0x212b610, GCancellable: 1 refs
1 objects

References:
#1
# GCancellable (+1/-0 = 1)
| # _start (+1/-0 = 1)
| | # __libc_start_main (+1/-0 = 1)
| | | # main (+1/-0 = 1)
| | | | # g_object_new (+1/-0 = 1)

I opened this PR in the hope it is useful to others.

[danni]

I don't really know what all the colours etc mean. This probably needs some doco.

In general if it's slowing things down too much then might you not be better off with Valgrind? Part of the point of this tool was to not slow things down like Valgrind does.

[Lekensteyn]

Valgrind is unusably slow and meanwhile a better tool has popped up, LeakSanitizer.

The slowness here referred to unwinding the full stack. LSan also needs to do that (and alternatively offers an even slower option, controllable via ASAN_OPTIONS=fast_unwind_on_malloc=0). LSan however is a compile-time instrumentation and cannot be used at runtime.

So I think that this patch does offer an advantage if LSan is not available/usable. When disabled (default), it does not cause a slowdown.

The color choices were arbitrary but can indeed be documented (in README?):

The call stack is printed as a tree where items have the format NAME (refs_count / unrefs_count = difference). An uninteresting tree item (= ref count matches unref count) is colored grey. Items with mismatching ref/unref counts are colored as follows:

• The regular text is blue.
• The refs_count is yellow.
• The unrefs_count is red.
• The difference is yellow if there are leaks, and red if there are more unrefs than refs.

[danni]

BtTree ?

[Lekensteyn]

A trie is a data structure also known as prefix tree. "BtTrie" = "prefix tree for backtraces storage".

[danni]

Please stick to the existing GNU/GNOME coding style for things like blocks. It makes the code easier to read. Also be very strict and explicit about how memory and references are passed around because the worst thing is when the memory checking tool leaks memory.

[Lekensteyn]

Thank you for your feedback, I'll address your comments and return later.