On Fri, 2009-08-28 at 15:11 -0400, Joly, Robert (CAR:9D30) wrote:
> > 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.
>
My guess, the name initialization is the first thing that uses this
code. When it does, it grabs a 16K block. As other things grow past
this allotment, the new memory (also in 16K blocks) gets blamed on the
first user.
Maybe Scott can verify this.
>
>
> Any update on the DNS SRV lookup leaks?
Yes, my initial fix was correct but not correctly placed.
res_ninit and res_nquery require res_nclose.
When I first added res_nclose, I missed a "break" path that jumped over
the fix.
-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/
