[nanomsg] Re: tracking down pipe/anon inode leaks
- From: George Lambert <marchon@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 24 Jan 2015 10:44:13 -0500
The software library should be cleaning them up on disconnect or abort.
I suggest we add track down in the code if and where they are actually
released, and make sure that the code is being called properly.
G.
On Fri, Jan 23, 2015 at 8:41 PM, Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
wrote:
> sockets are files, everything is a file, whatever just use the rm command
>
> On Fri, Jan 23, 2015 at 7:24 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote:
>
>> On linux, looking in /proc/PID/fd, it looks the leaked fd are eventfd.
>>
>> from /proc
>> lr-x------ 1 vagrant vagrant 64 Jan 24 00:13 0 -> /dev/null
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 1 -> /dev/pts/5
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 10 -> socket:[170235]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 11 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 12 -> socket:[173591]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 13 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 14 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 15 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 16 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 17 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 18 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 19 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 2 -> /dev/pts/5
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 20 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 21 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 22 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 23 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 3 -> /dev/tty
>> lr-x------ 1 vagrant vagrant 64 Jan 24 00:13 4 -> /dev/urandom
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 5 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 6 -> anon_inode:[eventpoll]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 7 -> anon_inode:[eventfd]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 8 -> socket:[173551]
>> lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 9 -> anon_inode:[eventpoll]
>> vagrant@precise64:/proc/15001/fd$
>>
>>
>> On Fri, Jan 23, 2015 at 3:20 PM, Jason E. Aten <j.e.aten@xxxxxxxxx>
>> wrote:
>>
>>> Does anyone have tips or tricks for tracking down leaking file
>>> descriptors? According to lsof, they appear to be pipes (OSX) and
>>> "anonymous inodes" (Linux). Any suggestions? I'm at a loss.
>>>
>>> Details: I'm using push/pull nanomsg (updated yesterday; most recent
>>> from github) sockets between a client and a server. It looks like every
>>> client connection to the server results in the server leaking more file
>>> descriptors. On OSX, I see pipes left open. condensed "lsof -p 34334 -Fnt"
>>> output shows these are leaked (OSX):
>>>
>>> tPIPE:n->0x95df5be7a4700aff
>>>
>>> tPIPE:n->0x95df5be7a46fee1f
>>>
>>> tPIPE:n->0x95df5be79ddeb75f
>>>
>>> tPIPE:n->0x95df5be7a16570df
>>>
>>> tPIPE:n->0x95df5be7a165702f
>>>
>>> tPIPE:n->0x95df5be79ddeae6f
>>>
>>> tPIPE:n->0x95df5be7a47006df
>>>
>>> tPIPE:n->0x95df5be7ada5a0ff
>>>
>>> tPIPE:n->0x95df5be7a165912f
>>>
>>> tPIPE:n->0x95df5be7a46ff0df
>>>
>>> tPIPE:n->0x95df5be7ac4c2ecf
>>>
>>> tPIPE:n->0x95df5be7ac4c499f
>>>
>>> tPIPE:n->0x95df5be7a470041f
>>>
>>> tPIPE:n->0x95df5be7ac4c554f
>>>
>>> tPIPE:n->0x95df5be7a46ffbdf
>>>
>>> tPIPE:n->0x95df5be7a46ff39f
>>>
>>> tPIPE:n->0x95df5be7a46fe94f
>>>
>>> tPIPE:n->0x95df5be7a165a1af
>>>
>>> tPIPE:n->0x95df5be7a470057f
>>>
>>> tPIPE:n->0x95df5be7a46fe68f
>>>
>>> On Linux it is anonymous inodes that are leaking. Output from "lsof -p
>>> 2332 -Fnt":
>>>
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>> t0000:nanon_inode
>>>
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Jason
>>
>> --
>> Jason E. Aten, Ph.D.
>> j.e.aten@xxxxxxxxx
>> 650-429-8602
>> linkedin: https://www.linkedin.com/pub/jason-e-aten-ph-d/18/313/45a
>>
>
>
>
> --
>
> Bent Cardan
> nothingsatisfies.com | bent@xxxxxxxxxxxxxxxxxxxx
>
--
P THINK BEFORE PRINTING: is it really necessary?
This e-mail and its attachments are confidential and solely for the
intended addressee(s). Do not share or use them without approval. If
received in error, contact the sender
and delete them.
Other related posts:
