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: callback_func ??? (address) in shared_lib.so original_func Libunwind will give us this: callback_func shared_lib_func 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
