[Top][All Lists]

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

[***SPAM***] Re: [Linphone-developers] OPTIONS transaction handling

From: Aymeric Moizard
Subject: [***SPAM***] Re: [Linphone-developers] OPTIONS transaction handling
Date: Wed, 31 Jan 2007 11:48:52 +0100 (CET)

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....




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,

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,
  osip_set_kill_transaction_callback(osip ,OSIP_NICT_KILL_TRANSACTION,
  osip_set_kill_transaction_callback(osip ,OSIP_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:

Linphone-developers mailing list

Linphone-developers mailing list

reply via email to

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