Subject: Re: CVS commit: src/lib/libc/stdlib
To: None <ad@netbsd.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: source-changes
Date: 01/02/2008 23:34:24
> On Fri, Dec 28, 2007 at 09:24:24PM +0900, YAMAMOTO Takashi wrote:
>
> > > Module Name: src
> > > Committed By: ad
> > > Date: Sat Dec 1 22:44:44 UTC 2007
> > >
> > > Modified Files:
> > > src/lib/libc/stdlib: jemalloc.c
> > >
> > > Log Message:
> > > Back out the per-cpu arena changes. With this, ld.so magically stops
> > > loading libc/libpthread twice -- which does not make sense, because it
> > > has its own private malloc().
> > >
> > >
> > > To generate a diff of this commit:
> > > cvs rdiff -r1.14 -r1.15 src/lib/libc/stdlib/jemalloc.c
> > >
> > > Please note that diffs are not public domain; they are subject to the
> > > copyright notices on the relevant files.
> >
> > is there a recipe to reproduce the problem?
>
> Put the changes back into libc and some threaded applications will fail on
> i386, presumably because the memory layout changes somehow. Firefox 2.0.0.6
> fails for me. With the changes backed out, I still see a native java binary
> mmap'ing libc and libpthread twice, but it still seems happy enough to work.
> Also, there are reports that this always happens on alpha.
>
> Andrew
unfortunatey firefox-2.0.0.11 seems to work fine for me
and i've almost lost my access to an alpha recently.
anyway thanks for explanation.
YAMAMOTO Takashi