Re: 2.6.16-mm1 leaks in dvb playback (found)

[Adrian Bridgett <adrian@smop.co.uk>]

On Fri, Mar 31, 2006 at 02:07:27 -0800 (-0800), David S. Miller wrote:
> Strange, can you strace the process and follow the socket
> operations your application performs?  Something unique
> is occuring in that app since there have not been other
> reports of this problem that I am aware of.

The strace output is the same when run under both kernels (a leaking
one and a non-leaking one):

7384  socket(PF_FILE, SOCK_STREAM, 0)   = 7
7384  connect(7, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
7384  recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"hosts\0", 6}],
      msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET,
      cmsg_type=SCM_RIGHTS, {8}}, msg_flags=0}, MSG_NOSIGNAL) = 6
7384  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7
7384  setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
7384  bind(7, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
7384  listen(7, 1)                      = 0
7384  accept(7, 0x81546e4, [0])         = -1 EAGAIN (Resource temporarily unavailable)
7384  accept(7, 0x81546e4, [0])         = -1 EAGAIN (Resource temporarily unavai
[repeated lots and lots ....]

So I guess I was _completely_ wrong and that it's the failure case
that is leaking.

It also looks like dvbstream is being a tad silly so I'll go and have
a look at that (userspace stuff I stand a chance with).

Thanks,

Adrian