Hi Ole, Yes, that fixes it! With that patch my NAT test works, no more assertion failures.
/ Elias On Fri, 2020-05-08 at 10:06 +0200, Ole Troan wrote: > Hi Elias, > > Thanks for finding that one. > Can you verify that this patch fixes it: > https://gerrit.fd.io/r/c/vpp/+/26951 nat: fix per thread data > vlib_main_t usage take 2 [NEW] > > Best regards, > Ole > > > On 7 May 2020, at 22:57, Elias Rudberg <elias.rudb...@bahnhof.net> > > wrote: > > > > 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 (#16281): https://lists.fd.io/g/vpp-dev/message/16281 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] -=-=-=-=-=-=-=-=-=-=-=-
