Right, sorry, I've pinged the Responsible Parties offline to fix the problem.
vec_len(vlib_mains) will be 1 in an init routine. Start_threads() which builds
the final vlib_mains vector doesn't occur until just prior to main dispatch
loop entry.
vec_elt_at_index (...) is meant to catch this sort of problem...
Dave
-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Elias Rudberg
Sent: Thursday, May 7, 2020 4:58 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Assertion failure in nat_get_vlib_main() in snat_init()
Hello,
With the current master branch (def78344) we now get an assertion failure on
startup, here:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff462e801 in __GI_abort () at abort.c:79
#2 0x00000000004071f3 in os_panic ()
at vpp/src/vpp/vnet/main.c:366
#3 0x00007ffff550d7d9 in debugger ()
at vpp/src/vppinfra/error.c:84
#4 0x00007ffff550d557 in _clib_error (how_to_die=2, function_name=0x0,
line_number=0,
fmt=0x7fffacbc0310 "%s:%d (%s) assertion `%s' fails")
at vpp/src/vppinfra/error.c:143
#5 0x00007fffacac659e in nat_get_vlib_main (thread_index=4)
at vpp/src/plugins/nat/nat.c:2557
#6 0x00007fffacabd7a5 in snat_init (vm=0x7ffff639b980
<vlib_global_main>)
at vpp/src/plugins/nat/nat.c:2685
#7 0x00007ffff60b9f66 in call_init_exit_functions_internal
(vm=0x7ffff639b980 <vlib_global_main>,
headp=0x7ffff639bfa8 <vlib_global_main+1576>, call_once=1,
do_sort=1)
at vpp/src/vlib/init.c:350
#8 0x00007ffff60b9e88 in vlib_call_init_exit_functions
(vm=0x7ffff639b980 <vlib_global_main>,
headp=0x7ffff639bfa8 <vlib_global_main+1576>, call_once=1)
at vpp/src/vlib/init.c:364
#9 0x00007ffff60ba011 in vlib_call_all_init_functions
(vm=0x7ffff639b980 <vlib_global_main>)
at vpp/src/vlib/init.c:386
#10 0x00007ffff60df1f8 in vlib_main (vm=0x7ffff639b980 <vlib_global_main>,
input=0x7fffb4b2afa8)
at vpp/src/vlib/main.c:2171
#11 0x00007ffff6166405 in thread0 (arg=140737324366208)
at vpp/src/vlib/unix/main.c:658
#12 0x00007ffff5531954 in clib_calljmp ()
at vpp/src/vppinfra/longjmp.S:123
#13 0x00007fffffffcf30 in ?? ()
#14 0x00007ffff6165f97 in vlib_unix_main (argc=57, argv=0x71d520)
at vpp/src/vlib/unix/main.c:730
#15 0x00000000004068d8 in main (argc=57, argv=0x71d520)
at vpp/src/vpp/vnet/main.c:291
The code looks like this (this part was added in a recent commit it
seems):
always_inline vlib_main_t *
nat_get_vlib_main (u32 thread_index)
{
vlib_main_t *vm;
vm = vlib_mains[thread_index];
ASSERT (vm);
return vm;
}
So it is looking at vlib_mains[thread_index] but that is NULL, apparently.
Since this happens at startup, could it be that vlib_mains has not been
initialized yet, it is too early to try to access it?
Is vlib_mains[thread_index] supposed to be initialized by the time when
vlib_call_all_init_functions() runs?
Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16278): https://lists.fd.io/g/vpp-dev/message/16278
Mute This Topic: https://lists.fd.io/mt/74060018/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
