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