RE: [Linphone-developers] linphone memory consumption

[Thomas Reitmayr]

Hi Jean-Paul,
I had a similar problem, although I cannot remember the rate at which
memory was eaten. It all occurred with OPTIONS requests, which my SIP
provider sends with every reregistration, therefore memory was leaking
without any other activity like calls.
This is fixed with 1.7.0 and up, so please try 1.7.1. For more details I
appended the email discussion about the leaks.
BTW, I too use linphone (actually yeaphone) on an embedded device (NSLU2)
which works very stable with 1.7.1!
Regards,
-Thomas

--- Thomas Reitmayr <address@hidden> schrieb:

> Datum: Wed, 31 Jan 2007 09:36:42 -0800 (PST)
> Von: Thomas Reitmayr <address@hidden>
> Betreff: Re: [Linphone-developers] OPTIONS transaction handling
> An: address@hidden
> 
> Hi Aymeric,
> regarding the first issue - I later saw myself that it was fixed in some
> version quite a while ago, but it still seems to be a potential memory
> leak as the "kill" callback for IST never gets initialized and therefore
> never called (if I haven't overlooked something). Therefore I appended
> the fix below.
> 
> About the second problem, I am aware that the eXosip version used for
> linphone is a snapshot with some of the bugs at that time. As this
> memory leak problem was quite serious on my embedded system due to the
> frequent options requests my VOIP service provider sends, I eventually
> found a fix which works for me. If there could be a problem needing the
> OPTIONS later in the call context (as you describe it), it did not
> happen with linphone for me - and I am still happy ;)
> Anyway, it is somehow what the latest eXosip does and it is appended
> below, too.
> 
> --- linphone-1.6.0/exosip/jcallback.c    2006-08-09 15:01:57.000000000
> +0200
> +++ linphone-1.6.0-yea/exosip/jcallback.c    2007-01-28
> 18:45:12.000000000 +0100
> @@ -1874,7 +1874,7 @@ eXosip_set_callbacks(osip_t *osip)
>    
>    osip_set_kill_transaction_callback(osip ,OSIP_ICT_KILL_TRANSACTION,
>                   &cb_ict_kill_transaction);
> -  osip_set_kill_transaction_callback(osip ,OSIP_NIST_KILL_TRANSACTION,
> +  osip_set_kill_transaction_callback(osip ,OSIP_IST_KILL_TRANSACTION,
>                   &cb_ist_kill_transaction);
>    osip_set_kill_transaction_callback(osip ,OSIP_NICT_KILL_TRANSACTION,
>                   &cb_nict_kill_transaction);
> --- linphone-1.6.0/exosip/udp.c    2006-08-25 15:32:39.000000000 +0200
> +++ linphone-1.6.0-yea/exosip/udp.c    2007-01-28 18:45:12.000000000
> +0100
> @@ -783,6 +783,8 @@ static void eXosip_process_new_options(o
>        return ;
>      }
>  
> +  osip_list_add(eXosip.j_transactions, transaction, 0);
> +  
>    evt_answer = osip_new_outgoing_sipmessage(answer);
>    evt_answer->transactionid =  transaction->transactionid;
>  
> Thanks for your answer,
> -Thomas
> 
> 
> ----- Ursprüngliche Mail ----
> Von: Aymeric Moizard <address@hidden>
> An: Simon Morlat <address@hidden>
> CC: address@hidden
> Gesendet: Mittwoch, den 31. Januar 2007, 11:48:52 Uhr
> Betreff: [***SPAM***] Re: [Linphone-developers] OPTIONS transaction
> handling
> 
> 
> On Wed, 31 Jan 2007, Simon Morlat wrote:
> 
> > Hi Thomas,
> >
> > Thanks for your deep study inside eXosip and libosip2.
> > I cc Aymeric Moizard, maintainer of libosip2:
> 
> I'm registred to the linphone's mailing list :)
> 
> > Actually I plan to move linphone to eXosip2, so the question for me
> are the
> > following memory leak and bugs fixed in eXosip2 ?
> > Aymeric, can you answer this question ?
> 
> The second issue you have with setting callback with 
> "osip_set_kill_transaction_callback" has been fixed in newer version
> long 
> time ago. It was not generating bug at run time because the code within 
> the callback methods are identical.
> 
> For your OPTIONS issue, I guess it's fixed in eXosip2. In initial
> version of eXosip1, OPTIONS was stored in "call" context so that it
> was potentially used later for a call: in eXosip2, it's managed outside
> any call context and stored in the list of "unknown" transaction
> managed by eXosip2. Once those transaction reach the completed state,
> ressource are released automatically within eXosip2. (osip never
> release transaction ressource)
> 
> I won't solve memory issue in eXosip1: it's more than two years old
> for me....
> 
> Aymeric
> 
> > Thanks
> >
> > Simon
> >
> > Le mercredi 24 janvier 2007 21:58, Thomas Reitmayr a écrit :
> >> Hi Simon,
> >> I still try to track down how transaction handling works for an
> OPTIONS
> >> dialog in linphone, respectively eXosip, to find out about the memory
> leak
> >> I wrote about earlier.
> >>
> >> The following is what I think happens for this kind of transaction:
> >> 1. The OPTIONS request is received. No matching transaction is found
> in
> >> libosip2 so it gets accepted and a transaction record is allocated.
> 2. The
> >> NIST state machine is executed until the transaction reaches the
> >> 'Completed' state. 3. The transaction is removed from the libosip2's
> list
> >> of transactions by one of the cb_*_kill_transaction routines, however
> at
> >> that exact point it cannot be removed from memory as libosip2 still
> needs
> >> it internally (in the loop going through all transactions). 4. Now
> after
> >> processing in libosip2 the transaction record could be removed from
> memory.
> >>
> >> For other types of transactions the last step (4) seems to be
> performed
> >> using a copy of a pointer to the transaction record and investigating
> the
> >> transaction's state. However I have not found the OPTIONS transaction
> being
> >> referenced by one of these lists in eXosip, so with removing the
> pointer in
> >> libosip2 all references are gone and the memory is lost.
> >>
> >> I have also performed some tests using netcat to confirm that steps 1
> - 3
> >> are executed, but 4 seems to be missing. However I might be wrong in
> some
> >> points of my investigation, so please correct me. My main question is
> still
> >> about step 4 - how it works or how it is supposed to work to finally
> >> release the allocated memory. Thanks in advance,
> >> -Thomas
> >>
> >> PS: A bit off-topic: During studying the code I found a possible bug
> in the
> >> following code: osip_set_kill_transaction_callback(osip
> >> ,OSIP_ICT_KILL_TRANSACTION, &cb_ict_kill_transaction);
> >>   osip_set_kill_transaction_callback(osip
> ,OSIP_NIST_KILL_TRANSACTION,
> >>                  &cb_ist_kill_transaction);
> >>   osip_set_kill_transaction_callback(osip
> ,OSIP_NICT_KILL_TRANSACTION,
> >>                  &cb_nict_kill_transaction);
> >>   osip_set_kill_transaction_callback(osip
> ,OSIP_NIST_KILL_TRANSACTION,
> >>                  &cb_nist_kill_transaction);
> >> The second function call should use OSIP_IST_KILL_TRANSACTION,
> otherwise
> >> IST transactions might not be removed from libosip2's list.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ___________________________________________________________
> >> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
> Mail:
> >> http://mail.yahoo.de
> >>
> >>
> >> _______________________________________________
> >> Linphone-developers mailing list
> >> address@hidden
> >> http://lists.nongnu.org/mailman/listinfo/linphone-developers
> >
> >
> > _______________________________________________
> > Linphone-developers mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> >
> >
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers
> 
> 
> 
> 
> 
>               
> ___________________________________________________________ 
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers
> 


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com