[nanomsg] Re: tracking down pipe/anon inode leaks
- From: "Jason E. Aten" <j.e.aten@xxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 24 Jan 2015 12:05:33 -0800
I found the leak. It was in my application code, not in the nanomsg
library.
On Sat, Jan 24, 2015 at 7:44 AM, George Lambert <marchon@xxxxxxxxx> wrote:
> 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.
>
--
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
Other related posts:
