[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: Mon, 29 Jun 2009 11:52:14 -0700
User-agent: Thunderbird (X11/20070604)

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 ?


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
lt-linpho  1815    cameron    9u     IPv4    1553336                 UDP
lt-linpho  1815    cameron   10u     IPv4    1553357                 UDP
lt-linpho  1815    cameron   11u     IPv4    1553378                 UDP
lt-linpho  1815    cameron   12u     IPv4    1553458                 UDP

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

Attachment: mtu.patch
Description: Text Data

reply via email to

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