On Tue, 17 Feb 2009 21:30:48 -0800 Edward Pilatowicz wrote: > 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. 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.)
it is possible and likely that both libc malloc/free and libast _ast_malloc/_ast_free would be called by ksh e.g., there are many libc functions that call malloc/free and those might be bound to the libc functions any function that uses sbrk() must dance with others that may be doing the same; part of that dance is to not contract memory lower than the current sbrk() region what does the function scribble() do its called by (presumably the libumem) free() can you run the same test with libumem configured with sbrk() vs mmap()?
