Update: resolved.
Thanks to Prakash for quick turn-around testing and valgrind reports of
potential fixes.
The remaining items in the valgrind report fit into two categories and can be
ignored:
1- uses Utl{link/chain/pool} code (eg.
SipMessage::SipMessageFieldProps::initNames)
According to Scott: "These are the internal linking structures used by all the
UtlContainer classes.
Rather than suffer the overhead and potential heap fragmentation problems
associated with the frequent allocation and
freeing of many many small objects, these are allocated in large blocks and
never returned - they are stored in pools
for reuse instead. The only way those pools are ever emptied is when the
process exits."
2- small number of leaks in code that probably does not clean up correctly on
shutdown. Most of these are 1,2,3 blocks.
Two cases (SipTransaction::doFirstSend and SipTransaction::recurseDnsChildren)
show 20-60 separate blocks.
I compared two valgrind reports, one contained results from many hours (50-70)
into the soak test,
the other contained results of one hour of soak test.
The number of leaks was similar in both reports (22/29 for one hour, 29/52 for
many hours).
The leak appears to be caused by undeleted SipMessageEvents and the contained
SipMessages.
I don't think this is a problem since the number isn't growing much over time
and an examination of the code
shows theses items are normally deleted properly. These are probably just lost
during the shutdown process.
-ke
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
