On 5/30/23 09:34, Ales Musil wrote: > > > On Mon, May 29, 2023 at 7:15 PM Ilya Maximets <i.maxim...@ovn.org > <mailto:i.maxim...@ovn.org>> wrote: > > On 5/25/23 08:33, 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 map 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 usage for SIGSEGV is determined during compilation > > based on available libraries. Libunwind has higher priority > > if both methods are available to keep the compatibility with > > current behavior. > > > > 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" or equivalent 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>> > > --- > > v2: Extend the current use of libunwind rather than replacing it. > > v3: Allow vlog_fd to be also 0. > > Return the backtrace log from monitor in updated form. > > Return use of the "vlog_direct_write_to_log_file_unsafe". > > v4: Rebase on top of current master. > > Address comments from Ilya: > > Address the coding style issues. > > Make sure that the backrace received by monitor doesn't > > have more than maximum allowed frames. > > Change the backtrace_format to accept delimiter. > > Remove unnecessary checks in the tests. > > v5: Rebase on top of current master. > > Address missed comment from v3: > > Reaname the vlog_fd to vlog_get_log_file_fd_unsafe to reflect that > > this is really unsafe. > > Return the ovsdb backtrace to correct position in log and > > keep the previous format. > > --- > > include/openvswitch/vlog.h | 3 + > > lib/backtrace.c | 116 +++++++++++++++++++++++++------------ > > lib/backtrace.h | 57 +++++++++++------- > > lib/fatal-signal.c | 52 +++++++++++++++-- > > lib/ovsdb-error.c | 12 +--- > > lib/vlog.c | 7 +++ > > m4/openvswitch.m4 | 9 ++- > > tests/atlocal.in <http://atlocal.in> | 2 + > > tests/daemon.at <http://daemon.at> | 45 ++++++++++++++ > > 9 files changed, 227 insertions(+), 76 deletions(-) > >
<snip> > > @@ -77,41 +83,75 @@ log_backtrace_at(const char *msg, const char *where) > > } > > > > ds_put_cstr(&ds, where); > > - VLOG_ERR("%s", backtrace_format(&b, &ds)); > > + ds_put_cstr(&ds, " backtrace:\n"); > > + backtrace_format(&b, &ds, "\n"); > > + VLOG_ERR("%s", ds_cstr_ro(&ds)); > > > > ds_destroy(&ds); > > } > > > > +static bool > > +read_received_backtrace(int fd, void *dest, size_t len) > > +{ > > + VLOG_WARN("%s fd %d", __func__, fd); > > + fcntl(fd, F_SETFL, O_NONBLOCK); > > This breaks the windows build: > > [00:06:56] lib/backtrace.c(97): error C4013: 'fcntl' undefined; assuming > extern returning int > [00:06:56] c:\openvswitch_compile\lib\ovs-rcu.h(228): warning C4311: > 'type cast': pointer truncation from 'void *' to 'long'lib/backtrace.c(97): > error C2065: 'F_SETFL': undeclared identifier > [00:06:56] > [00:06:56] lib/backtrace.c(97): error C2065: 'O_NONBLOCK': undeclared > identifier > > Please, protect this function with ifdefs. > > > Done, where can I see windows compilation to prevent this in future? You can setup AppVeyor CI (https://www.appveyor.com) for your github fork. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev