-
Bug
-
Resolution: Done
-
High
-
None
-
20.05
-
None
Version: v20.05-14~gd4b5fdde4
Reproduce: use multi threads vpp, set dhcp client intfc GigabitEthernet0/7/0
When vpp is used in multi threads/workers, the dhcp client causes the vpp crash.
the backtrace is
#0 0x00007ffff53c7387 in raise () from /lib64/libc.so.6
#1 0x00007ffff53c8a78 in abort () from /lib64/libc.so.6
#2 0x000000000040858e in os_panic () at /data/workspace/vpp/src/vpp/vnet/main.c:366
#3 0x00007ffff61688eb in debugger () at /data/workspace/vpp/src/vppinfra/error.c:84
#4 0x00007ffff6168cd6 in _clib_error (how_to_die=2, function_name=0x0, line_number=0, fmt=0x7fffb3d2b1d0 "%s:%d (%s) assertion `%s' fails") at /data/workspace/vpp/src/vppinfra/error.c:143 #5 0x00007fffb3cba1e5 in vlib_time_now (vm=0x7ffff7f81780 <vlib_global_main>) at /data/workspace/vpp/src/vlib/main.h:299
#6 0x00007fffb3cbd0db in dhcp_client_for_us (bi=636440, b=0x10026d8600, ip=0x10026d870e, udp=0x10026d8722, dhcp=0x10026d872a) at /data/workspace/vpp/src/plugins/dhcp/client.c:282
#7 0x00007fffb3ce0688 in dhcp_proxy_to_client_input (vm=0x7fffb474dcc0, node=0x7fffb4cbf900, from_frame=0x7fffb4c78000) at /data/workspace/vpp/src/plugins/dhcp/dhcp4_proxy_node.c:568
#8 0x00007ffff7ed7b44 in dispatch_node (vm=0x7fffb474dcc0, node=0x7fffb4cbf900, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb4c78000, last_time_stamp=4188694816810460)
at /data/workspace/vpp/src/vlib/main.c:1235
#9 0x00007ffff7ed82ff in dispatch_pending_node (vm=0x7fffb474dcc0, pending_frame_index=4, last_time_stamp=4188694816810460) at /data/workspace/vpp/src/vlib/main.c:1403
#10 0x00007ffff7ed9fc2 in vlib_main_or_worker_loop (vm=0x7fffb474dcc0, is_main=0) at /data/workspace/vpp/src/vlib/main.c:1862
#11 0x00007ffff7edaa29 in vlib_worker_loop (vm=0x7fffb474dcc0) at /data/workspace/vpp/src/vlib/main.c:1996
#12 0x00007ffff7f1bda5 in vlib_worker_thread_fn (arg=0x7fffbc2bb180) at /data/workspace/vpp/src/vlib/threads.c:1842
#13 0x00007ffff61876b8 in clib_calljmp () at /data/workspace/vpp/src/vppinfra/longjmp.S:123
#14 0x00007fef4f5fec10 in ?? ()
#15 0x00007ffff7f15bc0 in vlib_worker_thread_bootstrap_fn (arg=0x7fffbc2bb180) at /data/workspace/vpp/src/vlib/threads.c:584
I checked the newest code, this commit 77d9838282 introduced this bug.
in vlib_time_now under this case,
vm->thread_index is main thread, __os_thread_index is the worker thread.