Hi,
I'm getting a SIGSEGV in VPP trying to send a lot of traffic in one direction
via a TCP connection. I've enabled the VLIB_BUFFER_TRAJECTORY_TRACE, and I'm
getting this:
Context trace for bi 28664834 b 0x7fff5cd8bf00, visited 3
ip4-lookup (238)
ip4-rewrite (230)
ip4-lookup (238)
Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
vlib_increment_combined_counter (byte_increment=1448, packet_increment=1,
index=4294967295, cpu_index=<optimized out>, cm=0x7fffb5bec40c)
at /home/sratliff/vpp/build-data/../src/vlib/counter.h:258
258 new_bytes = old_bytes + byte_increment;
(gdb) bt
#0 vlib_increment_combined_counter (byte_increment=1448, packet_increment=1,
index=4294967295, cpu_index=<optimized out>,
cm=0x7fffb5bec40c) at
/home/sratliff/vpp/build-data/../src/vlib/counter.h:258
#1 vnet_interface_output_node (vm=<optimized out>, node=<optimized out>,
frame=<optimized out>)
at /home/sratliff/vpp/build-data/../src/vnet/interface_output.c:624
#2 0x00007ffff77567d2 in dispatch_node (vm=0x7ffff79a9240 <vlib_global_main>,
node=0x7fffb591d240, type=<optimized out>,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=<optimized out>,
last_time_stamp=21044750699247852)
at /home/sratliff/vpp/build-data/../src/vlib/main.c:998
#3 0x00007ffff7756b85 in dispatch_pending_node (vm=vm@entry=0x7ffff79a9240
<vlib_global_main>, p=0x7fffb6c5a244,
last_time_stamp=<optimized out>) at
/home/sratliff/vpp/build-data/../src/vlib/main.c:1136
#4 0x00007ffff775732b in vlib_main_loop (vm=0x7ffff79a9240 <vlib_global_main>)
at /home/sratliff/vpp/build-data/../src/vlib/main.c:1545
#5 vlib_main (vm=vm@entry=0x7ffff79a9240 <vlib_global_main>,
input=input@entry=0x7fffb5e9efa0)
at /home/sratliff/vpp/build-data/../src/vlib/main.c:1681
#6 0x00007ffff7790373 in thread0 (arg=140737347490368) at
/home/sratliff/vpp/build-data/../src/vlib/unix/main.c:507
#7 0x00007ffff6a07c40 in clib_calljmp () at
/home/sratliff/vpp/build-data/../src/vppinfra/longjmp.S:110
#8 0x00007fffffffd4d0 in ?? ()
#9 0x00007ffff7790d02 in vlib_unix_main (argc=<optimized out>, argv=<optimized
out>)
at /home/sratliff/vpp/build-data/../src/vlib/unix/main.c:575
#10 0x0000000000000000 in ?? ()
(gdb)
I've seen a couple of paths on the back-trace - this one, and one in mtrie.h.
It appears that the ip4-lookup sends the packet off to re-write, and the
Ethernet header *is* applied. Then, ip4_rewrite decides to send the packet back
to lookup, and of course, the current_data is pointing at the Ethernet header,
not the IP header. My surmise is that this has something to do with the
adjacency processing. Is there any way to lengthen the amount of time that an
adjacency is seen to be "good"? It looks like traffic is caught in the
timeframe where VPP is ARPing, looking to refresh the adjacency, and this
traffic is misdirected. Or, I could be way out in left field...
Any pointers would be appreciated.
Regards,
Stan
============================================================================================================================================
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
