On Wed, Apr 10, 2024 at 02:10:20PM +0200, Ilya Maximets wrote:
> On 4/6/24 00:08, Ilya Maximets wrote:
> > Currently, calls like ovs_assert() just print out a condition that
> > caused assertion to fail.  But it may be not enough to understand what
> > exactly has happened, especially if assertion failed in some generic
> > function like dp_packet_resize() or similar.
> > 
> > Print the stack trace along with the abort message to give more context
> > for the later debugging.
> > 
> > This should be especially useful in case the issue happens in an
> > environment with core dumps disabled.
> > 
> > Adding the log to vlog_abort() to cover a little more cases where
> > VLOG_ABORT is called and not only assertion failures.
> > 
> > It would be nice to also have stack traces in case of reaching the
> > OVS_NOT_REACHED().  But this macro is used in some places as a last
> > resort and should not actually do more than just stopping the process
> > immediately.  And it also can be used in contexts without logging
> > initialized.  Such a change will need to be done more carefully.
> > Better solution might be to use VLOG_ABORT() where appropriate instead.
> > 
> > Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
> > ---
> >  lib/vlog.c       | 10 ++++++++--
> >  tests/library.at |  4 +++-
> >  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> If this change is accepted, I'd also suggest backporting it to 3.3.
> It is a debug-only change that touches only the code executed under
> fatal failure conditions, so should be safe enough.  Backporting
> will allow us easier debugging in to-be-LTS release.  And also OVN
> 24.03 LTS can make use of it this way as well.

Acked-by: Simon Horman <ho...@ovn.org>

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to