[Gluster-devel] Libunwind
Niels de Vos
ndevos at redhat.com
Tue Sep 13 06:34:10 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160913/1ffa8244/attachment.sig>
More information about the Gluster-devel
mailing list