On Fri, Mar 17, 2023 at 2:42 PM Ilya Maximets <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.0(backtrace_capture+0x1e) [0x7fc5db298dfe] > > /lib64/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 > > Signed-off-by: Ales Musil <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 | 1 + > > tests/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. > > 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 :) > > > Best regards, Ilya Maximets. > > Thanks, Ales -- Ales Musil Senior Software Engineer - OVN Core Red Hat EMEA <https://www.redhat.com> amu...@redhat.com IM: amusil <https://red.ht/sig> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
