On Sat, Feb 21, 2009 at 03:58:38PM +0100, Roland Mainz wrote: > Edward Pilatowicz wrote: > > On Wed, Feb 18, 2009 at 07:55:00PM +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. > > > > > > Can you please test whether the problem goes away if you do a $ export > > > VMCHECK=m # before running the test (this _requires_ at least libast > > > from B106 or higher) ? > > > > nope. > > Uhm... that sounds like a "|sbrk()|/|brk()|-consumer collision" can be > ruled-out in this case (VMCHECK=m forces the libast allocator to use > |mmap()| for memory allocations (and a different allocation layout)). > > > ---8<--- > > edp at jurassic-x4600$ uname -a > > SunOS jurassic-x4600 5.11 snv_108 i86pc i386 i86pc > > edp at jurassic-x4600$ VMCHECK=m LC_ALL=en_US.ISO8859-1 /usr/bin/type type > > assertion failed: *membgn != patterns[pattern], file: ../common/malloc.c, > > line: 93 > > Where does this assertion come from ? >
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/rtld/common/malloc.c#93 > > zsh: IOT instruction (core dumped) VMCHECK=m LC_ALL=en_US.ISO8859-1 > > /usr/bin/type type > > Does the problem still happen if you use "bash" instead of "zsh" ? > Uhm... of course it does. the problem is not it the invoking shell, but in the ksh93 process. ed
