|
|
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at www.tux.org/lkml/">http://www.tux.org/lkml/
|
|