Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/lib/libc/stdlib
> 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
Home |
Main Index |
Thread Index |
Old Index