On 3/17/23 14:49, Ales Musil wrote: > > > On Fri, Mar 17, 2023 at 2:42 PM Ilya Maximets <i.maxim...@ovn.org > <mailto:i.maxim...@ovn.org>> wrote: > > On 3/17/23 14:03, Ales Musil wrote: > > Use the backtrace functions that is provided by libc > > this allows us to get backtrace that is independent of > > the current memory ap of the process. Which in turn can > > be used for debugging/tracing purpose. The backtrace > > is not 100% accurate due to various optimizations, most > > notably "-fomit-frame-pointer" and LTO. This might result > > that the line in source file doesn't correspond to the > > real line. However, it should be able to pinpoint at least > > the function where the backtrace was called. > > > > The backtrace is not marked as signal safe however the backtrace > > manual page gives more detailed explanation why it might be the > > case [0]. Load the "libgcc" in advance within the "fatal_signal_init" > > which should ensure that subsequent calls to backtrace* do not > > call malloc and are signal safe. > > > > The typical backtrace will look similar to the one below: > > /lib64/libopenvswitch-3.1.so > <http://libopenvswitch-3.1.so>.0(backtrace_capture+0x1e) [0x7fc5db298dfe] > > /lib64/libopenvswitch-3.1.so > <http://libopenvswitch-3.1.so>.0(log_backtrace_at+0x57) [0x7fc5db2999e7] > > /lib64/libovsdb-3.1.so.0(ovsdb_txn_complete+0x7b) [0x7fc5db56247b] > > /lib64/libovsdb-3.1.so.0(ovsdb_txn_propose_commit_block+0x8d) > [0x7fc5db563a8d] > > ovsdb-server(+0xa661) [0x562cfce2e661] > > ovsdb-server(+0x7e39) [0x562cfce2be39] > > /lib64/libc.so.6(+0x27b4a) [0x7fc5db048b4a] > > /lib64/libc.so.6(__libc_start_main+0x8b) [0x7fc5db048c0b] > > ovsdb-server(+0x8c35) [0x562cfce2cc35] > > > > backtrace.h elaborates on how to effectively get the line > > information associated with the addressed presented in the > > backtrace. > > > > [0] > > backtrace() and backtrace_symbols_fd() don't call malloc() > > explicitly, but they are part of libgcc, which gets loaded > > dynamically when first used. Dynamic loading usually triggers > > a call to malloc(3). If you need certain calls to these two > > functions to not allocate memory (in signal handlers, for > > example), you need to make sure libgcc is loaded beforehand > > > > Reported-at: https://bugzilla.redhat.com/2177760 > <https://bugzilla.redhat.com/2177760> > > Signed-off-by: Ales Musil <amu...@redhat.com <mailto:amu...@redhat.com>> > > --- > > include/openvswitch/vlog.h | 4 +- > > lib/backtrace.c | 71 ++++++++------------------ > > lib/backtrace.h | 76 +++++++++++++--------------- > > lib/daemon-unix.c | 1 - > > lib/fatal-signal.c | 100 +++++++++---------------------------- > > lib/ovsdb-error.c | 15 ++---- > > lib/vlog.c | 14 ++---- > > m4/openvswitch.m4 | 20 +++----- > > tests/atlocal.in <http://atlocal.in> | 1 + > > tests/daemon.at <http://daemon.at> | 71 > ++++++++++++++++++++++++++ > > 10 files changed, 165 insertions(+), 208 deletions(-) > > Hi, Ales. I didn't read the patch, but I do not agree with the name. :) > > > Hi Ilya, > > > I'm not sure if need to replace libunwind. Can we use libunwind whenever > possible and fall back to backtrace, if libunwind is not available? > > > The BZ talked about replacing, I guess it might be possible to have both and > use whatever is > configured.
Unless both solutions are available on the same range of systems, including different OS, OS versions, compilers, libc implementation, and so on, we should keep libunwind support. > > > > Also, libgcc is part of GCC, right? How does it work with clang? We > probably shouldn't mention it in logs if it's not what is actually used. > > > It works with clang as well (I've tested it), it's part of libc and I have no > idea why it's called libgcc :) Maybe I'm reading that wrong but on my fedora system libgcc is provided by the gcc package, not glibc. > > > > > Best regards, Ilya Maximets. > > > Thanks, > Ales > > -- > > Ales Musil > > Senior Software Engineer - OVN Core > > Red Hat EMEA <https://www.redhat.com> > > amu...@redhat.com <mailto:amu...@redhat.com> IM: amusil > > <https://red.ht/sig> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
