[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: |
Simon Morlat |
Subject: |
Re: [Linphone-developers] Problem with Linphone 3.1.2 on Blackfin BF536 |
Date: |
Mon, 29 Jun 2009 10:04:10 +0200 |
User-agent: |
KMail/1.11.4 (Linux/2.6.29-2-amd64; KDE/4.2.4; x86_64; ; ) |
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