On Wed, Feb 18, 2009 at 01:03:25AM -0500, Glenn Fowler wrote: > > 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() >
i think scribble is internal to the linker. i also think it's a red-herring. > can you run the same test with libumem configured with sbrk() vs mmap()? hm. i just upgraded my desktop from 106 to 107 and i can't reproduce the problem there anymore, but the good news is i can still reproduce it on another machine running 108. it doesn't seem to matter if we use mmap or sbrk. ---8<--- e...@jurassic-x4600$ UMEM_OPTIONS=sbrk LC_ALL=en_US.ISO8859-1 /bin/time /bin/sleep 1 time: command terminated abnormally. real 3.7 user 0.0 sys 0.0 e...@jurassic-x4600$ UMEM_OPTIONS=mmap LC_ALL=en_US.ISO8859-1 /bin/time /bin/sleep 1 time: command terminated abnormally. real 2.3 user 0.0 sys 0.0 ---8<--- _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
