[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Cameron Barfield
Subject: Re: [Linphone-developers] Problem with Linphone 3.1.2 on Blackfin BF536
Date: Fri, 26 Jun 2009 13:20:22 -0700
User-agent: Thunderbird (X11/20070604)

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-> lt-linpho 1815 cameron 9u IPv4 1553336 UDP smithers.voiplab:59258-> lt-linpho 1815 cameron 10u IPv4 1553357 UDP smithers.voiplab:39725-> lt-linpho 1815 cameron 11u IPv4 1553378 UDP smithers.voiplab:59070-> lt-linpho 1815 cameron 12u IPv4 1553458 UDP smithers.voiplab:52785->

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");
                        printf("rtp socket closed ok\n");
                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");
                        printf("rtcp socket closed ok\n");
                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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]