Nicolas Williams wrote:
> On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote:
> > Nicolas Williams wrote:
> > > I strongly recommend that ksh93/AST on Solaris use the standard
> > > allocator, OR, if you insist on having a private allocator, that it
> > > provide an allocator with standar
Roland Mainz wrote:
>>> A while aho when I was in MPK there was a discussion whether it would
>>> make sense to rip-out the existing |libc::malloc()| and port the libast
>>> implementation over to libc. The only problem so far was finding enougth
>>> free time to do it... ;-(
>> I think I'd rather
On Thu, 19 Feb 2009 11:18:56 -0800 Jonathan Adams wrote:
> On Thu, Feb 19, 2009 at 07:37:32PM +0100, Roland Mainz wrote:
> > AFAIK this will not work properly if someone uses libumem via LD_PRELOAD
> > since libumem&co. are not async-signal safe and ksh93 relies on this
> > feature.
> I asked thi
On Thu, Feb 19, 2009 at 07:37:32PM +0100, Roland Mainz wrote:
> Nicolas Williams wrote:
> > On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote:
> > > Nicolas Williams wrote:
> > > > I strongly recommend that ksh93/AST on Solaris use the standard
> > > > allocator, OR, if you insist on hav
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
On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote:
> Nicolas Williams wrote:
> > I strongly recommend that ksh93/AST on Solaris use the standard
> > allocator, OR, if you insist on having a private allocator, that it
> > provide an allocator with standard names, so that: a) it interposes
aren't there some solaris build modes that bind certain
library symbols at link time?
if so, are malloc/free ever in that set of bound symbols?
re the libumem problems
the corruption shows up with libumem using either mmap or sbrk
so, along with libc malloc/free + ast malloc/free working ok witho
On Wed, Feb 18, 2009 at 09:59:26AM -0800, Jonathan Adams wrote:
> On Wed, Feb 18, 2009 at 11:39:02AM -0600, Nicolas Williams wrote:
> > malloc()/free() from libc (or interposed via pre-loading).
> >
> > Rationales:
> >
> > [...]
> > - you need to make sure no more than one allocator uses brk()/
On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote:
> 3. |libc::malloc()| cannot be used in signal handlers while the AST
> version allows this
How does it allow this?
Cheers,
- jonathan
> A while aho when I was in MPK there was a discussion whether it would
> make sense to rip-out the
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
Glenn Fowler wrote:
> aren't there some solaris build modes that bind certain
> library symbols at link time?
Yes, building with -B direct, though those can still be overridden
by objects marked by the linker as interposers.
http://docs.sun.com/app/docs/doc/819-0690/aehzq?a=view
http://blogs.sun.
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 th
Glenn Fowler wrote:
> On Fri, 13 Feb 2009 15:19:30 -0800 Edward Pilatowicz wrote:
> > 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 en
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 mma
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
>
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.
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 libu
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:
> > > >
> > > > What does $ /usr/xpg4/bin/file /usr/bin/sleep /usr/bin/alias # say on
> > > > the system where this fails ?
> >
> > well not mentioning
well not mentioning libumem in the original message was quite an omission
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
Stephen Hahn wrote:
> * Roland Mainz [2009-02-13 22:36]:
> > Edward Pilatowicz wrote:
> > > make sure you're sitting down because this may come as a bit of a shock,
> > > but ksh93 seems to break when run in non-C locals with time/ptime.
> > >
> > > 6805584 ksh93 in non-C locale breaks time/ptime
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,fa
* Roland Mainz [2009-02-13 22:36]:
> Edward Pilatowicz wrote:
> > make sure you're sitting down because this may come as a bit of a shock,
> > but ksh93 seems to break when run in non-C locals with time/ptime.
> >
> > 6805584 ksh93 in non-C locale breaks time/ptime
> [snip]
>
> Erm... the bug is
22 matches
Mail list logo
