On 5/30/23 09:34, Ales Musil wrote:
>
>
> On Mon, May 29, 2023 at 7:15 PM Ilya Maximets <[email protected]
> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
> > ---
> > 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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
