Обсуждение: osprey buildfarm member has been failing for a long while

Поиск
Список
Период
Сортировка

osprey buildfarm member has been failing for a long while

От
Tom Lane
Дата:
"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.oparser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o
nodes/SUBSYS.ooptimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o
tcop/SUBSYS.outils/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?
        regards, tom lane

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

От
Andrew Dunstan
Дата:
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.oparser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o
nodes/SUBSYS.ooptimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o
tcop/SUBSYS.outils/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?
>
>     
>   

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.

cheers

andrew

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

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

От
Tom Lane
Дата:
Rémi Zara <remi_zara@mac.com> writes:
>> Tom Lane wrote:
>>> 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.

Yeah, data segment size would be the most likely culprit if this is a
ulimit thing.
        regards, tom lane

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

От
Rémi Zara
Дата:
Le 28 mai 06 à 17:42, Tom Lane a écrit :

> Rémi Zara <remi_zara@mac.com> writes:
>>> Tom Lane wrote:
>>>> 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.
>
> Yeah, data segment size would be the most likely culprit if this is a
> ulimit thing.

Changing this limit and removing ccache made the trick.
Next run will try and re-enable ccache (this build lasted nearly 11.5
hours :-)

Regards,

Rémi Zara