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

[Cameron Barfield]

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

mtu.patch
Description: Text Data