Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 May 2020 11:42:49 +0000
From:      "Reynolds, Paul" <paul.reynolds@redcom.com>
To:        Michael Tuexen <tuexen@fh-muenster.de>
Cc:        "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org>
Subject:   RE: SCTP deadlock
Message-ID:  <c1880120cbb647f4a2b8a41e4a2995b2@redcom.com>
In-Reply-To: <AE4DAC88-CB7F-4AAF-B2BF-A79A85C45F16@fh-muenster.de>
References:  <112525e87fce467e97f1d455ef9bf685@redcom.com> <AE4DAC88-CB7F-4AAF-B2BF-A79A85C45F16@fh-muenster.de>

next in thread | previous in thread | raw e-mail | index | archive | help

> > I have a set of programs that use sctp for communication. For now these=
 processes are all running on the same machine. They are using SEQPACKET mo=
de to send messages back and forth. Each process has multiple threads, but =
only one socket. The threads are mutex protected such that the socket canno=
t be accessed by more than one thread at a time. Very occasionally one of t=
he sockets will become permanently blocked on an sctp send or receive call =
and I am trying to figure out why. In the cases where it has become blocked=
 on a send call, the corresponding receive process is not blocked and can s=
end/receive data to other destinations. These processes can run fine for mo=
nths and then suddenly run into this problem. I have been able to reproduce=
 this once or twice by subjecting the system to unrealistically high levels=
 of traffic, but it still takes several days or more to reproduce the probl=
em. I now have a system that is stuck in this mode and am trying to gather =
as much information
> >  as possible.
> >=20
> > How should I go about debugging this? The output of sockstat and netsta=
t have not been very helpful up to this point.
> Which version of FreeBSD are you using?
>=20

I am using FreeBSD 11.3p8.

Thanks,
Paul




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c1880120cbb647f4a2b8a41e4a2995b2>