Messages in this thread | | | Date | Fri, 31 Mar 2006 19:47:33 +0100 | Subject | Re: 2.6.16-mm1 leaks in dvb playback (found) | From | Adrian Bridgett <> |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |