On Sat, Feb 21, 2009 at 03:49:23PM +0100, Roland Mainz wrote: > Jonathan Adams wrote: > > On Wed, Feb 18, 2009 at 11:39:02AM -0600, Nicolas Williams wrote: > > > On Sun, Feb 15, 2009 at 01:21:28AM -0500, Glenn Fowler wrote: > > > > ast provides its own malloc/free, and those calls are mapped > > > > to _ast_malloc/_ast_free in the ksh/ast code for opensolaris builds > > > > so that call to free() in the stack trace was not done directly by > > > > any ksh/ast code > > > > > > I believe this is a bad idea. On Solaris it'd be best to use the global > > > malloc()/free() from libc (or interposed via pre-loading). > > > > > > Rationales: > > > > > > - you'll end up with two allocators, which means... > > > - ...you need to be real sure that some allocation won't be free()ed by > > > the wrong allocator, and... > > > - 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. > > Is this the case for the libc and libumem implementations ?
Yes; I believe the only problematic user in ON is /bin/vi, which is linked against libmapmalloc for that reason. (it uses brk() to reset the break) libumem detects the presence of libmapmalloc, and defaults to the mmap backend in that case. Cheers, - jonathan
