On Fri, 2009-08-28 at 15:59 -0400, Kathleen Eccles wrote:
> 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.
Plausible - the bottom several levels of any call stack that uses the
internal UtlContainer links are the same, so it's likely that the
valgrind reporting mechanisms conflate them.
Technically, valgrind is correct - these are 'leaks' in the sense that
the nothing ever frees that memory, but in this case it's by design, and
unless the UtlContainers themselves are leaked, the memory is reused.
_______________________________________________
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/
