[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

-------------- 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