jdarcy at redhat.com
Mon Sep 12 13:30:32 UTC 2016
I looked into this a bit over the weekend. Unfortunately, while libunwind *does* get function names for calls in shared libraries, it *doesn't* seem to handle calls through function pointers very well. Imagine that original_func in your main program finds shared_lib_func via dlsym and calls it via a function pointer, and that shared_lib_func then calls callback_func back in the main program. If we try to get a backtrace at this point, glibc will give us this:
??? (address) in shared_lib.so
Libunwind will give us this:
Notice that the last frame (original_func) is missing. Also, neither has file names or line numbers. I did find a method that will give us those, while also handling both shared libraries and function pointers well: invoke gdb to run against the current process, using "-batch" and "-ex" to run just the backtrace command. We can even get backtraces for all threads instead of just one. I looked a bit into using the relevant gdb functions as a library, but didn't get anywhere with that. While invoking a whole new process makes this a bit too heavyweight for most cases, for the case where we're about to exit anyway (which is where this all started for me) it might be pretty useful.
More information about the Gluster-devel