Florin Coras <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
, 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.

Andreas


> Regards,
> Florin
>
>
> On Nov 21, 2018, at 1:36 AM, Andreas Schultz <
> andreas.schu...@travelping.com> wrote:
>
> Florin Coras <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> 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
>> <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
>> <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 <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
> <+49-391-81%2090%2099%200>
> Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
> <+49-391-81%2090%2099%20299>
> 39108 Magdeburg                     Email:  i...@travelping.com
> GERMANY                             Web:    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
Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
39108 Magdeburg                     Email:  i...@travelping.com
GERMANY                             Web:    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 (#11355): https://lists.fd.io/g/vpp-dev/message/11355
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to