On Wed, Feb 18, 2009 at 06:43:33AM +0100, Roland Mainz wrote: > Edward Pilatowicz wrote: > > On Wed, Feb 18, 2009 at 06:14:59AM +0100, Roland Mainz wrote: > > > Glenn Fowler wrote: > > > > On Fri, 13 Feb 2009 15:19:30 -0800 Edward Pilatowicz wrote: > > > > we were careful in the solaris build to add an _ast_ prefix > > > > to any libast function that might interfere with solaris libc > > > > > > > > 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 > > > > > > Right... but it seems something has trashed the heap managed by > > > |libc::malloc()| - either something is writing randomly into areas where > > > it shouldn't write to... or maybe we hit bug in Solaris. > > > > > > > is there a description on how libumem allocates/frees physical memory? > > > > > > Uhm... good question... looking at > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libumem/common/ > > > it seems to have at least support for |sbrk()| and |mmap()|. > > > > libumem is a drop in place replace for libc malloc()/free(). so if an > > application never uses libc malloc()/free(), then it should never use > > libumem malloc/free. > > Erm... that's not correct. libc/libnsl/etc.-internal functions may call > |libc::malloc()| even if your own application doesn't contain a single > call to |malloc()| ... >
libraries use free()/malloc(). correct. so if you want to provide alternate versions of these functions, everyone needs to use them. that's exactly what happens when you preload libumem, or libmapmalloc, or any other malloc replacement. > > as you've noticed, it can be configured to use > > either sbrk() or mmap(). now, since libast has it's own malloc()/free() > > replacements, i would think that you need to somehow ensure that no-one > > (not even the linker) calls into libc malloc/free. otherwise you could > > end up with libc and libast allocating from the same heap... (which if > > you run with libumem, would be initialized to 0xdeadbeef.) > > Uhm... how should this happen ? libast and libc use _different_ ELF > symbols for their matching malloc versions (e.g. |libc::malloc()| vs. > |libast::_ast_malloc()|) and can both happily co-exist in one and the > same application. > ah, so you're malloc/free have different names. then that shouldn't be a problem as long as you ensure that you're not allocating from the same backing store as libc/libumem malloc/free. > AFAIK the problem we're seeing here is that something corrupts the heap > managed by |libc::malloc()| when ksh93 is doing a |setlocale()| call. > But that's all theory for now since I can't reproduce the crash on my > side even after trying > hm. i don't know. fyi, libumem (with the environment settings described in the bug report) will write the 0xdeadbeef pattern to free'd memory. this helps catch applications that try to access free'd memory. looking at the bug report, i see there was some internal analysis done. i've attached that analysis to this email. it seems that we are passing around 0xdeadbeef pointers... ed
