Re: [Linphone-developers] Problem with Linphone 3.1.2 on Blackfin BF536

[Simon Morlat]

Hi Cameron,

Thank you very much for your investigation and this sucesful patch !
I completely missed these mtu discover related socket. They were finally not 
related to RTP ports.
I have commited your patch it in svn/git trees.

Simon

Le lundi 29 juin 2009 20:52:14, Cameron Barfield a écrit :
> It was the sockets created by ms_discover_mtu() (mediastreamer2/src/mtu.c).
> They were never closed, under any circumstances.
>
> Here's a patch that closes the sockets. I'm not sure of the patch format
> you like, but this one can be applied with 'patch -p0 < mtu.patch' in
> mediastreamer2/src/
>
> Simon Morlat wrote:
> > Looks very strange !
> > DId you see the socket opened in coreapi/misc.c  for stun checks ?
> > Normally they should be closed too.
> > Otherwise could it be a kernel bug ?
> >
> > Simon
> >
> > Le vendredi 26 juin 2009 22:20:22, Cameron Barfield a écrit :
> >> Simon --
> >>
> >> The only (non-printout) modifications I've made to linphone are in
> >> linphonec to automate the call generation and termination processes and
> >> in linphonecore.c to hardcode the authentication information.
> >>
> >> lsof snippet:
> >> lt-linpho  1815    cameron    8u     IPv4    1553318                 UDP
> >> smithers.voiplab:52601->10.0.1.17:55799
> >> lt-linpho  1815    cameron    9u     IPv4    1553336                 UDP
> >> smithers.voiplab:59258->10.0.1.17:10186
> >> lt-linpho  1815    cameron   10u     IPv4    1553357                 UDP
> >> smithers.voiplab:39725->10.0.1.17:1934
> >> lt-linpho  1815    cameron   11u     IPv4    1553378                 UDP
> >> smithers.voiplab:59070->10.0.1.17:59258
> >> lt-linpho  1815    cameron   12u     IPv4    1553458                 UDP
> >> smithers.voiplab:52785->10.0.1.17:28332
> >>
> >> Those appear to correspond with the RTP connections.
> >>
> >> I also added some code to rtp_session_release_sockets() to check the
> >> return value of close_socket() and print the status:
> >>
> >> void rtp_session_release_sockets(RtpSession *session)
> >> {
> >>    int err = 0;
> >>    if (session->rtp.socket>=0)
> >>    {
> >>            err = close_socket (session->rtp.socket);
> >>            if(err != 0)
> >>                    printf("error closing RTP socket\n");
> >>            else
> >>                    printf("rtp socket closed ok\n");
> >>    }
> >>    else
> >>    {
> >>            printf("rtp socket < 0)\n");
> >>    }
> >>    if (session->rtcp.socket>=0)
> >>    {
> >>            err = close_socket (session->rtcp.socket);
> >>            if(err != 0)
> >>                    printf("error closing RTCP socket\n");
> >>            else
> >>                    printf("rtcp socket closed ok\n");
> >>    }
> >>    else
> >>    {
> >>            printf("rtcp socket < 0)\n");
> >>    }
> >>
> >> When I run with that code, I see that the close_socket() is reporting
> >> that the sockets are closed correctly.
> >>
> >> Simon Morlat wrote:
> >>> I agree. Indeed these are the symptoms of a leak of file descriptors.
> >>> However my understanding is that the 1024 limit is per-process, so the
> >>> leak would be within linphone or one its dependency, or the program
> >>> that runs liblinphone if not linphonec.
> >>>
> >>> First thing to do is to check your own code (if you use liblinphone
> >>> directly or patched linphonec) for missing close() statements on opened
> >>> file descriptors or sockets.
> >>> Then try to instrument the code by overriding every function that
> >>> returns file descriptors (open, socket, pipe, socketpair...) and print
> >>> a backtrace, do the same thing for close(), and try to find the one
> >>> that gets leaked after the end of each call. Quite difficult unless
> >>> there exist some specialised library or glibc debugging option to do
> >>> that... Ask google.
> >>>
> >>> Simon
> >>>
> >>> Le vendredi 26 juin 2009 20:34:39, Nick Briggs a écrit :
> >>>> I'd suspect that some code is leaking file descriptors, and is hitting
> >>>> the default limit of 1024 open FDs -- i'd look at all the processes
> >>>> (sudo lsof) when it is in this broken state for some process that has
> >>>> an excessive number of FDs.   It likely one of the audio related
> >>>> processes that is being provoked by something Linphone is doing,
> >>>> rather than Linphone itself.
> >>>>
> >>>> Nick Briggs
> >>>> Palo Alto Research Center
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Linphone-developers mailing list
> >>>> address@hidden
> >>>> http://lists.nongnu.org/mailman/listinfo/linphone-developers