On Mon, Sep 12, 2016 at 09:30:32AM -0400, Jeff Darcy wrote: > 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. Thanks for the info. When you run gdb, did you use RPMs? Packages get build with stripped debuginfo that is placed in a -debuginfo sub-package. In case you get useful backtraces without installing the -debuginfo package, I think there is a benefit. If it only works with the -debuginfo installed there seems little advantage in using libunwind. Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
