Building gcc fails at target s-attrtab

Hello,

I installed Guix 0.8.3 on an Arch machine and tried to install zile,

because it has few dependencies. Though some files are downloaded from

hydra.gnu.org, guix tries to build packages. It fails at gcc's build at

target s-attrtab. When doing "guix pull", building also fails at

gcc-cross-boot0's target s-attrtab.

Looking around a bit, I found [0]. Apparently someone had the same

issue, though discussion broke off, because the reporter wasn't able to

provide the build log, so here it is for gcc-cross-boot0 (last 200

lines). Maybe we can just lift off where the previous discussion died.

Best regards,

Aljosha Papsch

[0] https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00427.html

Aljosha Papsch <lists@rpapsch.de> skribis:

Sounds like binaries for 0.8.3 have been GC’d from hydra.gnu.org, which

is unfortunate.

Hmm, OK.

Is this deterministic? That is, does it happen again if you rerun ‘guix

build zile’ or something like that?

The “Killed” here suggests an out-of-memory condition. Does

‘dmesg | tail’ reveal something like that?

How much memory does this machine have?

Thanks for your report!

Ludo’.

On Wed, Oct 21, 2015 at 06:38:17PM +0200, Ludovic Courtès wrote:

Maybe after each release, we should create a profile with all the packages

of this release (and delete it again after the next release)? Or are we

too low on disk space?

Andreas

Andreas Enge <andreas@enge.fr> skribis:

That was the plan, hence the ‘version-0.8.3’ branch but…

… probably.

Ludo’.

On 21.10.2015 18:38, Ludovic Courtès wrote:

Yes, "guix build zile" fails again at GCCs build. I attached the build

log just to be sure.

It got 4GB of RAM but none of swap. dmesg really shows something, please

see attachment. I'll try hooking up some swap and see how it goes.

I'm curious: How did you compile gcc in the past, where resources were

even more scarce? Did you always have a good load of swap for it to

succeed? I remember the rule "swap is 2 times ram", though in recent

years some are convinced that it worn off given the ever bigger RAM.

Aljosha

On 23.10.2015 01:04, Aljosha Papsch wrote:

I hooked up an old 4GB swap partition and during the build process it

was used a bit. This time, the build process got a little further, but

it got stuck again at another phase. Please see the attached build log.

The error message is "No space left on device", though the file system

on wich guix runs has 85GB left.

Dmesg isn't helpful this time, an error should appear between these two

messages:

[17910.001324] Adding 3948540k swap on /dev/mapper/fed-swap. Priority:-1

extents:1 across:3948540k FS

[18118.026198] wlp0s26u1u2: AP 00:00:00:00:00:00 changed bandwidth, new

config is 2412 MHz, width 1 (2412/0 MHz)

For the fun of it, I plotted the memory consumption using gnuplot. While

the build process was busy, I captured memory usage with "free -s1 >

memory.log". A little scheme helped transform that into a data file for

gnuplot. The x axis is the datum, e.g. nth capture. Near the end, free

memory goes up sharply. This is where the build process failed and the

machine went idle.

Aljosha

On Fri, 23 Oct 2015 22:56:04 +0200

Aljosha Papsch <lists@rpapsch.de> wrote:

the error message is near the end of the log:

../../gcc-4.9.3/gcc/tree-ssa-ccp.c:2751:1: fatal error: error writing to /tmp/nix-build-gcc-4.9.3.drv-0/cc5mntgw.s: No space left on device

}

I assume /tmp is part of / on your system. How much free space do you have

there? That's where the building is done.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

On Sun, 25 Oct 2015 13:35:22 +0100

Aljosha Papsch <lists@rpapsch.de> wrote:

Glad to hear it worked out :)

my /tmp is a 6GB tmpfs, because for a while I was building and building

texlive, and after whatever else was in /tmp it needed almost 5GB. But that

should be the biggest package.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

On 24.10.2015 22:35, Efraim Flashner wrote:

That was the nudge in the right direction. I didn't think of /tmp being

mounted as tmpfs, which lead to wrong assumption that guix had 85GB

space left. /tmp is mounted with default options, which means size is

half the RAM (2GB). To increase tmpfs size, I remounted /tmp with

options "size=20G". These 20GB are backed by 50GB swap, which I

increased by reusing an old partition of another system as swap.

Now building zile suceeds and guix installed it successfully. I guess

the bug can be closed now as it appears to be a sole issue of memory

resources on this machine. Utilizing gnuplot again, the peak of RAM

usage is at approx. 1.8GB, while swap usage is at approx. 1.3GB. The

20GB tmpfs and 50GB swap is a bit much and I'll reduce it to 3GB tmpfs

and 6GB swap. I will see if this is sufficient in daily guix usage.

Aljosha

Aljosha Papsch <lists@rpapsch.de> skribis:

[...]

I regularly build it on my laptop, which has 8G of RAM and little swap.

The build machines behind hydra.gnu.org all have more than 4G of RAM, I

think.

Indeed, ‘genattrtab’ is a program in GCC used when building it. It’s a

problem that it needs so much memory. I would suggest reporting it if

nobody did that already.

Thanks,

Ludo’.

Aljosha Papsch <lists@rpapsch.de> skribis:

Ooh, that also explains the out-of-memory issue, then.

Well, thanks for finding it out!

Closing this bug now.

Ludo’.

tag 21720 notabug

close 21720

thanks