Hi,
Tracked it down. It's not the session logic, but the connection handling in
the proxy sample hs_app.
The proxy is calling vnet_disconnect_session on both sessions
in delete_proxy_session. That function is invoked from the disconnect and
reset callback. Turns out that calling vnet_disconnect_session on the
session the callback was invoked for, messes up the session state.
Andreas
Am Fr., 29. Mai 2020 um 14:32 Uhr schrieb Andreas Schultz <
andreas.schu...@travelping.com>:
> Hi,
>
> It seems that the {v4,v6}_session_hash is leaking entries. When creating
> large amounts of TCP session (incoming and outgoing) we are observing
> entries in the session_hash pointing to already deleted sessions.
>
> I have verified with a somewhat hackish check in session_delete that
> sometimes a session is deleted that still has an active entry in the
> session hash. The entry does not get deleted later. Under the right
> circumstances, that invalid entry is then picked up
> by session_lookup_connection_wt4, leading to crash.
>
> So far the cause seems to be the session_delete
> in session_transport_delete_notify when the status is STATE_CLOSED. I have
> no idea how the session ends up there.
>
> Regards,
> Andreas
>
> --
>
> Andreas Schultz
>
--
Andreas Schultz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16572): https://lists.fd.io/g/vpp-dev/message/16572
Mute This Topic: https://lists.fd.io/mt/74542352/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
