Re: [HACKERS] osprey buildfarm member has been failing for a long while

[Rémi Zara]

Le 28 mai 06 à 04:08, Andrew Dunstan a écrit :

Tom Lane wrote:

"osprey" hasn't been able to build HEAD since the GIN code was added.
I'm not sure that GIN is really to blame though, as the error looks
like an out-of-memory problem while trying to link the backend:


ld in malloc(): error: brk(2) failed [internal error]
gcc: Internal error: Abort trap (program ld)
Please submit a full bug report.
See <URL:http://www.netbsd.org/Misc/send-pr.html> for instructions.
gmake[2]: *** [postgres] Error 1

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g -L../../src/port -Wl,-R'/ data/postgresql/buildfarm/workdir/HEAD/inst/lib' -Wl,-E access/ SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/ SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/ SUBSYS.o ../../src/port/libpgport_srv.a -lintl -lcrypt -lm -o postgres Perhaps the swap space or ulimit setting on the box needs to be raised?

What kind of ulimit did you think of ?
I'll try upping the data segment size.

I don't think it's a swap problem. I've not seen the machine go much in the swap while running the build, but I've not checked since the failure appeared. I was sort of hoping the issue will resovle itself when the size of the link would change again...

Or maybe ccache is the culprit - there have been suspicions before that ccache is responsible for errors, but it's never been confirmed. Remi, can you try turning it off and see what happens? just comment out the CC => "cache gcc" line in the config file.

I'll try that.

Regards,

Rémi Zara

smime.p7s
Description: S/MIME cryptographic signature