Skip site navigation (1) Skip section navigation (2)

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

From: Rémi Zara <remi_zara(at)mac(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: osprey buildfarm member has been failing for a long while
Date: 2006-05-28 09:00:17
Message-ID: C7C21C1C-F9CA-42EF-8DDA-CD02A6B7F6FC@mac.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Marko KreenDate: 2006-05-28 11:45:39
Subject: Re: Inefficient bytea escaping?
Previous:From: Tom LaneDate: 2006-05-28 05:00:18
Subject: Re: [HACKERS] psql \copy warning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group