[nanomsg] Re: tracking down pipe/anon inode leaks
- From: "Jason E. Aten" <j.e.aten@xxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sun, 25 Jan 2015 13:07:31 -0700
https://github.com/glycerine/goq is my application, whose master branch now
contains the leak fix. There's also a branch of goq there called
nanomsg-instrumented that has a vendored copy of nanomsg with all calls to
eventfd, socket, pipe, etc logged so that I could bisect down in my code to
where the leaking eventfd call was coming from in my code.
> On Jan 25, 2015, at 4:42 AM, Amit Das <amit.das@xxxxxxxxxxxxx> wrote:
>
> Hi
> Can you post the code for benefit of all?
>
>> On 25 Jan 2015 01:35, "Jason E. Aten" <j.e.aten@xxxxxxxxx> wrote:
>> 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:
