aren't there some solaris build modes that bind certain library symbols at link time? if so, are malloc/free ever in that set of bound symbols?
re the libumem problems the corruption shows up with libumem using either mmap or sbrk so, along with libc malloc/free + ast malloc/free working ok without libumem, it doesn't look like sbrk() usage patterns is the culprit On Wed, 18 Feb 2009 12:06:54 -0600 Nicolas Williams wrote: > On Wed, Feb 18, 2009 at 09:59:26AM -0800, Jonathan Adams wrote: > > On Wed, Feb 18, 2009 at 11:39:02AM -0600, Nicolas Williams wrote: > > > malloc()/free() from libc (or interposed via pre-loading). > > > > > > Rationales: > > > > > > [...] > > > - you need to make sure no more than one allocator uses brk()/sbrk(); > > > > Again, this is not a problem, as long as: > > > > 1. neither sbrk() user assumes that consecutive calls return > > consecutive addresses, > > 2. no-one calls brk() to back up the break. > My statement of the brk()/sbrk() problem is certainly simplified, I > agree, but it's still roughly correct because we cannot guarantee that > an interposed allocator will meet (1) and (2). Without such a guarantee > we must guarantee that only one allocator uses brk()/sbrk() (and that > never the twain shall meet). > We're not about to stop using brk()/sbrk() in our allocators, so I think > this advice is correct: there can be only one allocator, either libc's > or an interposed one -- anything else is a disaster waiting to happen. > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
