Glenn Fowler wrote: > 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. > > aren't there some solaris build modes that bind certain > library symbols at link time?
That's "-Bdirect" which forces "direct bindings". However |libc::malloc()|, |libc::realloc()|, |libc::free()| are explicitly marked as "interposeable" that people can use libumem&co. for debugging purposes via LD_PRELOAD. > if so, are malloc/free ever in that set of bound symbols? See above. But in our case this doesn't matter since libast's memory allocator lives in it's own namespace prefixed with |_ast_*| and therefore shouldn't cause problems. > 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 My guess is that we have somehow a simple "pointer gone mad"-issue here which trashes the libc-controlled heap. The problem is that dbx's "check -access" feature is (xx@@@!!!-again) broken in B106 which leaves me with no good way to find this problem. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
