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

[Cameron Barfield]

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