> 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."
I'm not sure I understand how this behavior can lead to valgrind
reporting multi-magebyte leaks on initializing a names table with a
dozen small entries.
>
> 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.
Any update on the DNS SRV lookup leaks?
_______________________________________________
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/
