On Wed, Feb 18, 2009 at 12:39:02AM -0500, Glenn Fowler wrote: > > On Wed, 18 Feb 2009 06:14:59 +0100 Roland Mainz wrote: > > Glenn Fowler wrote: > > > well not mentioning libumem in the original message was quite an omission > > > Erm... AFAIK libumem isn't the source of the problem. Solaris's libumem > > is an alternative memory allocator which "overrides" the default > > |libc::malloc()| and provides configurable debugging aids (in a similar > > way as libast's internal memory corruption checks controlled via > > VMDEBUG/VMCHECK/&co. - see > > http://docs.sun.com/app/docs/doc/816-5168/umem-debug-3malloc?l=ja&a=view > > for some documentation). AFAIK Edward was only using libumem to > > track-down the source of the problem via libumem and the crash happens > > with and without it. > > that's not the impression I got from this message: > > > to reproduce the problem you have to have libumem loaded. > > i've changed the synopsys to be: > > ksh93+libumem+time/ptime is broken in non-C locales > > > > to run with libumem, set the following in your environment: > > ---8<--- > > LD_PRELOAD=libumem.so > > UMEM_DEBUG='audit=50,guards' > > UMEM_LOGGING=transaction,fail > > ---8<--- > > exaclty how is the problem reproduced and on what systems?
i saw the problem on my desktop. with libumem loaded and configured as explanied above. when i originally filed the bug, i didn't make any mention of libumem because, as i mentioned, i run everything with libumem. and anything that runs with libc, should run with libc+libumem. ed
