On Thu, Sep 08, 2016 at 10:33:25AM -0400, Vijay Bellur wrote: > On Thu, Sep 8, 2016 at 9:07 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: > > In a few places in our code (e.g. gf_log_callingfn) we use the "backtrace" and "backtrace_symbols" functions from libc to log stack traces. Unfortunately, these functions don't seem very smart about dynamically loaded libraries - such as translators, where most of our code lives. They give us the object plus offset from where the object was loaded into memory, which isn't that easy to turn into a function name (let alone a file and line number). It seems like libunwind can do better, getting at least to the function name. AFAICT it's supported and packaged on all of our platforms, though there might be version differences. Newer versions can supposedly get to file and line, which would be even better. Before I get further into this, two questions for all of you: > > > > (1) Has somebody already gone down this path? Does it work? > > > > (2) Are there any other reasons we wouldn't want to switch? > > > Cannot think of any. The BSD platforms seem to have libunwind and Mac > OS X doesn't have it apparently [1]. > > I have been thinking of fixing the recent Mac OS X compilation > problems and can address issues related to libunwind as part of that > activity. I think libunwind support should be optional, and by default our ./configure fails if --without-libunwind is not given. Possibly there is an alternative for Mac OS X, but it is not an OS we currently see a lot of users with, so missing some debugging there is not critical. Niels > > -Vijay > > [1] http://comments.gmane.org/gmane.comp.lib.unwind.devel/2199 > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
