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

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:
>>
>> 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
>> 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
>>
>> Perhaps the swap space or ulimit setting on the box needs to be
>> raised?

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...

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

>>
>>
>
> 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