[reSIProcate] resiprocate stack memeory leak?????
FrankYuan
frankyuan at emergent-netsolutions.com
Thu Sep 21 13:36:31 CDT 2006
After call generator stopped for 10 minutes, I found that the resip
statistics did not have any problem on these FIFO queues.
So I created core file and print the size of Transaction map.
There are still lot of TIDs in the transaction map. At least it is part
of culprit to hold memory.
Should there be a grarbage collection to free these lost TIDs?
Here are the log files:
20060921-125408.091 | TuSelector.cxx:71 | Stats message
20060921-125408.091 | StatisticsMessage.cxx:153 | RESIP:TRANSACTION
TU summary: 0 TRANSPORT 0 TRANSACTION 0 CLIENTTX 1998 SERVERTX 10690
TIMERS 0
Transaction summary: reqi 1225266 reqo 1200525 rspi 955555 rspo 1229993
Details: INVi 383069/S322324/F36145 INVo 344348/S322414/F0 ACKi 312462
ACKo 3223
60 BYEi 507150/S507141/F0 BYEo 307875/S307111/F0 CANi 22517/S507141/F0
CANo 2223
/S1550/F593 MSGi 0/S0/F0 MSGo 0/S0/F0 OPTi 0/S0/F0 OPTo 0/S0/F0 REGi
68/S64/F0 R
EGo 0/S0/F0 PUBi 0/S0/F0 PUBo 0/S0/F0 SUBi 0/S0/F0 SUBo 0/S0/F0 NOTi
0/S0/F0 NOT
o 0/S0/F0
Retransmissions: INVx 116463 BYEx 105757 CANx 1499 MSGx 0 OPTx 0 REGx 0
finx 0 n
onx 0 PUBx 0 SUBx 0 NOTx 0
20060921-125708.084 | TuSelector.cxx:71 | Stats message
20060921-125708.084 | StatisticsMessage.cxx:153 | RESIP:TRANSACTION
TU summary: 0 TRANSPORT 0 TRANSACTION 0 CLIENTTX 1998 SERVERTX 10690
TIMERS 0
Transaction summary: reqi 1225268 reqo 1200525 rspi 955555 rspo 1229995
Details: INVi 383069/S322324/F36145 INVo 344348/S322414/F0 ACKi 312462
ACKo 3223
60 BYEi 507150/S507141/F0 BYEo 307875/S307111/F0 CANi 22517/S507141/F0
CANo 2223
/S1550/F593 MSGi 0/S0/F0 MSGo 0/S0/F0 OPTi 0/S0/F0 OPTo 0/S0/F0 REGi
70/S66/F0 R
EGo 0/S0/F0 PUBi 0/S0/F0 PUBo 0/S0/F0 SUBi 0/S0/F0 SUBo 0/S0/F0 NOTi
0/S0/F0 NOT
o 0/S0/F0
Retransmissions: INVx 116463 BYEx 105757 CANx 1499 MSGx 0 OPTx 0 REGx 0
finx 0 n
onx 0 PUBx 0 SUBx 0 NOTx 0
20060921-130008.078 | TuSelector.cxx:71 | Stats message
20060921-130008.085 | StatisticsMessage.cxx:153 | RESIP:TRANSACTION
TU summary: 0 TRANSPORT 0 TRANSACTION 0 CLIENTTX 1998 SERVERTX 10690
TIMERS 0
Transaction summary: reqi 1225270 reqo 1200525 rspi 955555 rspo 1229997
Details: INVi 383069/S322324/F36145 INVo 344348/S322414/F0 ACKi 312462
ACKo 3223
60 BYEi 507150/S507141/F0 BYEo 307875/S307111/F0 CANi 22517/S507141/F0
CANo 2223
/S1550/F593 MSGi 0/S0/F0 MSGo 0/S0/F0 OPTi 0/S0/F0 OPTo 0/S0/F0 REGi
72/S68/F0 R
EGo 0/S0/F0 PUBi 0/S0/F0 PUBo 0/S0/F0 SUBi 0/S0/F0 SUBo 0/S0/F0 NOTi
0/S0/F0 NOT
o 0/S0/F0
Retransmissions: INVx 116463 BYEx 105757 CANx 1499 MSGx 0 OPTx 0 REGx 0
finx 0 n
onx 0 PUBx 0 SUBx 0 NOTx 0
(gdb) p (EnSipStack->myStack->mTransactionController->mClientTransactionMap)
warning: can't find class named `resip::SipStack', as given by C++ RTTI
$1 = {mMap = {_M_ht = {_M_node_allocator = {<No data fields>},
_M_hash = {<No data fields>},
_M_equals = {<binary_function<resip::Data,resip::Data,bool>> =
{<No data f
ields>}, <No data fields>},
_M_get_key = {<unary_function<std::pair<const resip::Data,
resip::Transact
ionState*>,const resip::Data>> = {<No data fields>}, <No data fields>},
_M_buckets =
{<_Vector_base<__gnu_cxx::_Hashtable_node<std::pair<const res
ip::Data, resip::TransactionState*>
>*,std::allocator<resip::TransactionState*>
>> = {<_Vector_alloc_base<__gnu_cxx::_Hashtable_node<std::pair<const
resip::Data
, resip::TransactionState*>
>*,std::allocator<resip::TransactionState*>,true>> =
{_M_start = 0x920bdd10, _M_finish = 0x920c9d14,
_M_end_of_storage = 0x920c9d14}, <No data fields>}, <No data
fields>
}, *_M_num_elements = 1998*}}}
(gdb) p (EnSipStack->myStack->mTransactionController->mServerTransactionMap)
warning: can't find class named `resip::SipStack', as given by C++ RTTI
$2 = {mMap = {_M_ht = {_M_node_allocator = {<No data fields>},
_M_hash = {<No data fields>},
_M_equals = {<binary_function<resip::Data,resip::Data,bool>> =
{<No data f
ields>}, <No data fields>},
_M_get_key = {<unary_function<std::pair<const resip::Data,
resip::Transact
ionState*>,const resip::Data>> = {<No data fields>}, <No data fields>},
_M_buckets =
{<_Vector_base<__gnu_cxx::_Hashtable_node<std::pair<const res
ip::Data, resip::TransactionState*>
>*,std::allocator<resip::TransactionState*>
>> = {<_Vector_alloc_base<__gnu_cxx::_Hashtable_node<std::pair<const
resip::Data
, resip::TransactionState*>
>*,std::allocator<resip::TransactionState*>,true>> =
{_M_start = 0x8cc3e790, _M_finish = 0x8cc567d4,
_M_end_of_storage = 0x8cc567d4}, <No data fields>}, <No data
fields>
}, _*M_num_elements = 10691*}}}
Thanks
Frank Yuan
Emergent-Netsolutions.com
972-359-6600
FrankYuan wrote:
> I am still working on it and will let you know as soon as I find
> anything related.
>
> Thanks
>
> Frank Yuan
> Emergent-Netsolutions.com
> 972-359-6600
>
>
>
> Byron Campen wrote:
>
>> This code was written long before my time here at resiprocate, so
>> I do not know. To those who are in the know, is this a relic that can
>> be safely done away with?
>>
>> Did you verify whether or not you had a genuine memory leak (this is
>> something I am very interested to know)?
>>
>> Best regards,
>> Byron Campen
>>
>>
>>
>>> My question why NoSize(0U-1) is used for mSize when clear func is
>>> called.
>>>
>>> mStateMachineFifo.size() may return either 0 or NoSize if the queue
>>> is empty.
>>>
>>> It should alway return 0 if the queue is empty and NoSize should not
>>> be used.
>>>
>>> NoSize causes confusion and is error prone.
>>>
>>> Thanks
>>>
>>> Frank Yuan
>>> Emergent-Netsolutions.com
>>> 972-359-6600
>>>
>>>
>>>
>>> Jason Fischl wrote:
>>>
>>>> On 9/20/06, Byron Campen <bcampen at estacado.net> wrote:
>>>>
>>>>> As for your questions about AbstractFifo, I am unsure why
>>>>> mSize is
>>>>> needed. Can anyone answer this (or, answer why clear is a no-op)?
>>>>>
>>>>>
>>>> The clear method is virtual and gets defined in the subclasses.
>>>>
>>>> I believe that mSize is there as an optimization.
>>>>
>>>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060921/6d776737/attachment.htm>
More information about the resiprocate-devel
mailing list