Ow, so the issue is the reset. Could you try to call stream_session_disconnect instead of stream_session_cleanup in the handle?
Florin > On Nov 22, 2018, at 6:51 AM, Andreas Schultz <andreas.schu...@travelping.com> > wrote: > > Hi, > > Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>> schrieb > am Mi., 21. Nov. 2018 um 18:33 Uhr: > >> On Nov 21, 2018, at 8:55 AM, Andreas Schultz <andreas.schu...@travelping.com >> <mailto:andreas.schu...@travelping.com>> wrote: >> >> Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>> >> schrieb am Mi., 21. Nov. 2018 um 17:18 Uhr: >> Hi Andreas, >> >> The trace lower suggests your tcp connection was freed but you still got >> data for it. tcp-input and the checks in established should prevent that >> from happening and the session layer should not receive any events after the >> transport notifies it that the session will cleaned up. > > I've found a way to reproduce the problem with a mostly unmodified vpp (see > attached patch for the changes). > It turns that the crash is triggered when a tcp client is aborting > (resetting) the connection the hard way with a RST. > > A normal connection close looks like this: > > Client Server (VPP) > ----- [FIN,ACK] ----> > <---- [FIN,ACK] ----- > ------- [ACK] ------> > > The crash occurs when the connection is aborted like this: > > Client Server (VPP) > ----- [RST,ACK] ----> > > For the unmodified VPP the crash looks like this: > > Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. > 0x00007ffff76abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) at > /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530 > 530 tc->flags &= ~TCP_CONN_DEQ_PENDING; > (gdb) bt > #0 0x00007ffff76abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) > at /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530 > #1 0x00007ffff76b1a6c in tcp46_established_inline (vm=0x7ffff708f340 > <vlib_global_main>, node=0x7fffb927a3c0, frame=0x7fffb7619800, is_ip4=1) at > /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2160 > #2 0x00007ffff76b1b01 in tcp4_established (vm=0x7ffff708f340 > <vlib_global_main>, node=0x7fffb927a3c0, from_frame=0x7fffb7619800) at > /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2171 > #3 0x00007ffff70043ec in dispatch_node (vm=0x7ffff708f340 > <vlib_global_main>, node=0x7fffb927a3c0, type=VLIB_NODE_TYPE_INTERNAL, > dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb7619800, > last_time_stamp=67427903546971 <tel:67427903546971>) > at /usr/src/components/vpp/src/vlib/main.c:1154 > #4 0x00007ffff70049cc in dispatch_pending_node (vm=0x7ffff708f340 > <vlib_global_main>, pending_frame_index=5, last_time_stamp=67427903546971 > <tel:67427903546971>) at /usr/src/components/vpp/src/vlib/main.c:1312 > #5 0x00007ffff700665f in vlib_main_or_worker_loop (vm=0x7ffff708f340 > <vlib_global_main>, is_main=1) at /usr/src/components/vpp/src/vlib/main.c:1739 > #6 0x00007ffff7006e38 in vlib_main_loop (vm=0x7ffff708f340 > <vlib_global_main>) at /usr/src/components/vpp/src/vlib/main.c:1813 > #7 0x00007ffff7007be4 in vlib_main (vm=0x7ffff708f340 <vlib_global_main>, > input=0x7fffb6bfffb0) at /usr/src/components/vpp/src/vlib/main.c:2006 > #8 0x00007ffff7062b90 in thread0 (arg=140737337946944) at > /usr/src/components/vpp/src/vlib/unix/main.c:606 > #9 0x00007ffff6e73c98 in clib_calljmp () from > /usr/src/components/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01 > #10 0x00007fffffffd230 in ?? () > #11 0x00007ffff706305d in vlib_unix_main (argc=34, argv=0x555555694230) at > /usr/src/components/vpp/src/vlib/unix/main.c:675 > #12 0x000055555555d404 in main (argc=34, argv=0x555555694230) at > /usr/src/components/vpp/src/vpp/vnet/main.c:272 > > The reason I discovered this is that my VPP HTTP server is sending a 302 > redirect with a Location header. In this case wget is doing something with > the connection that leads to the RST instead of a normal FIN. > > Regards > Andreas > > > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: i...@travelping.com > <mailto:i...@travelping.com> > GERMANY Web: http://www.travelping.com > <http://www.travelping.com/> > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > <http_redirect.patch>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11391): https://lists.fd.io/g/vpp-dev/message/11391 Mute This Topic: https://lists.fd.io/mt/19343385/21656 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
