> On Nov 21, 2018, at 8:55 AM, Andreas Schultz <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. > > So, apart from calling vnet_disconnect_session () on an rx event, have you > done anything else to the code? > > Not to the session code. I got a bit creative when creating the listening > session and feeding the packets to ip-input. > > The actual code for the session process is here: > https://gerrit.fd.io/r/c/15801/6/src/plugins/upf/upf_http_redirect_server.c#222 > > <https://gerrit.fd.io/r/c/15801/6/src/plugins/upf/upf_http_redirect_server.c#222> > , I still need to address you comments there, but I don't think that this > has anything to do with the crash. > > I'm going to test this a bit further with the http_server.
Ack. Do let me know what you find! Cheers, Florin > > Andreas > > > Regards, > Florin > > >> On Nov 21, 2018, at 1:36 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 Fr., 18. Mai 2018 um 08:12 Uhr: >> That http server is just example code that executes the contents of a get >> request as a cli commands within a spawned vpp process. So, if you want to >> disconnect _after_ the the reply is sent, call vnet_disconnect_session () at >> the end of http_cli_process. >> >> Came across this when searching for a similar problem. >> >> I tried exactly what Florin suggested in the rx_callback handle. Doing so >> result in segmentation in multiple places. >> >> The first in tcp_input: >> >> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. >> 0x00007ffff70d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) at >> /usr/src/vpp/src/vnet/tcp/tcp_input.c:530 >> 530 tc->flags &= ~TCP_CONN_DEQ_PENDING; >> (gdb) print tc >> $1 = (tcp_connection_t *) 0x0 >> (gdb) bt >> #0 0x00007ffff70d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) >> at /usr/src/vpp/src/vnet/tcp/tcp_input.c:530 >> #1 0x00007ffff70db8bb in tcp46_established_inline (vm=0x7ffff68f2340 >> <vlib_global_main>, node=0x7fffb6dc0600, frame=0x7fffb5e1afc0, is_ip4=1) at >> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2160 >> #2 0x00007ffff70db951 in tcp4_established (vm=0x7ffff68f2340 >> <vlib_global_main>, node=0x7fffb6dc0600, from_frame=0x7fffb5e1afc0) at >> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2171 >> #3 0x00007ffff6669ab2 in dispatch_node (vm=0x7ffff68f2340 >> <vlib_global_main>, node=0x7fffb6dc0600, type=VLIB_NODE_TYPE_INTERNAL, >> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5e1afc0, >> last_time_stamp=6761417783745271) >> at /usr/src/vpp/src/vlib/main.c:1109 >> #4 0x00007ffff666a092 in dispatch_pending_node (vm=0x7ffff68f2340 >> <vlib_global_main>, pending_frame_index=10, >> last_time_stamp=6761417783745271) at /usr/src/vpp/src/vlib/main.c:1267 >> #5 0x00007ffff666bd23 in vlib_main_or_worker_loop (vm=0x7ffff68f2340 >> <vlib_global_main>, is_main=1) at /usr/src/vpp/src/vlib/main.c:1694 >> #6 0x00007ffff666c4fc in vlib_main_loop (vm=0x7ffff68f2340 >> <vlib_global_main>) at /usr/src/vpp/src/vlib/main.c:1768 >> #7 0x00007ffff666d2a9 in vlib_main (vm=0x7ffff68f2340 <vlib_global_main>, >> input=0x7fffb53fffb0) at /usr/src/vpp/src/vlib/main.c:1961 >> #8 0x00007ffff66c7d2d in thread0 (arg=140737329963840) at >> /usr/src/vpp/src/vlib/unix/main.c:606 >> #9 0x00007ffff5ee2e04 in clib_calljmp () from >> /usr/src/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01 >> #10 0x00007fffffffd0f0 in ?? () >> #11 0x00007ffff66c81fa in vlib_unix_main (argc=44, argv=0x5555558939b0) at >> /usr/src/vpp/src/vlib/unix/main.c:675 >> #12 0x000055555555cce8 in main (argc=44, argv=0x5555558939b0) at >> /usr/src/vpp/src/vpp/vnet/main.c:272 >> >> After adding a check for tc == NULL, it crashes with >> >> 0: /usr/src/vpp/src/vnet/session/session.h:394 (session_get_from_handle) >> assertion `! pool_is_free (smm->wrk[thread_index].sessions, _e)' fails >> >> So it seems that is currently not possible to use vnet_disconnect_session () >> from a rx_callback directly. >> >> Any hints on how to disconnect the tcp session from the rx callback? >> >> Regards >> Andreas >> >> >> Florin >> >> >>> On May 17, 2018, at 10:52 PM, muziding <muziding...@163.com >>> <mailto:muziding...@163.com>> wrote: >>> >>> Hi >>> >>> I want to make the example of http server actively close the client >>> connection, instead of waiting for the client to close connection, after >>> http server has responded to the client request. What should I do? >> >> _._,_._,_ >> Links: >> >> You receive all messages sent to this group. >> >> >> View/Reply Online (#9328) <https://lists.fd.io/g/vpp-dev/message/9328> | >> Reply To Sender >> <mailto:fcoras.li...@gmail.com?subject=Private:%20Re:%20Re%3A%20%5Bvpp-dev%5D%20How%20to%20actively%20close%20the%20client%20connections%20in%20http%20server%3F%20%23vnet> >> | Reply To Group >> <mailto:vpp-dev@lists.fd.io?subject=Re:%20Re%3A%20%5Bvpp-dev%5D%20How%20to%20actively%20close%20the%20client%20connections%20in%20http%20server%3F%20%23vnet> >> | Mute This Topic <https://lists.fd.io/mt/19343385/675601> | New Topic >> <https://lists.fd.io/g/vpp-dev/post> >> >> >> >> Mute #vnet <https://lists.fd.io/mk?hashtag=vnet&subid=1480449> >> >> Change Your Subscription <https://lists.fd.io/g/vpp-dev/editsub/675601> >> Group Home <https://lists.fd.io/g/vpp-dev> >> Contact Group Owner <mailto:vpp-dev+ow...@lists.fd.io> >> Terms Of Service <https://lists.fd.io/static/tos> >> Unsubscribe From This Group <https://lists.fd.io/g/vpp-dev/unsub> >> _._,_._,_ >> >> >> >> >> -- >> -- >> Dipl.-Inform. Andreas Schultz >> >> ----------------------- enabling your networks ---------------------- >> Travelping GmbH Phone: +49-391-81 90 99 0 >> <tel:+49-391-81%2090%2099%200> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> <tel:+49-391-81%2090%2099%20299> >> 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 >> --------------------------------------------------------------------- > > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > <tel:+49-391-81%2090%2099%200> > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > <tel:+49-391-81%2090%2099%20299> > 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 > ---------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11356): https://lists.fd.io/g/vpp-dev/message/11356 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] -=-=-=-=-=-=-=-=-=-=-=-
