Building gcc fails at target s-attrtab

  • Done
  • quality assurance status badge
Details
4 participants
  • Andreas Enge
  • Efraim Flashner
  • Aljosha Papsch
  • Ludovic Courtès
Owner
unassigned
Submitted by
Aljosha Papsch
Severity
normal
A
A
Aljosha Papsch wrote on 20 Oct 2015 19:22
(address . bug-guix@gnu.org)
1445361729.24180.0@ara.uberspace.de
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

Attachment: file
Attachment: w0ym9mxwwmkf9m70mkldmybbryf454-gcc-cross-boot0-4.9.3.drv
L
L
Ludovic Courtès wrote on 21 Oct 2015 18:38
(name . Aljosha Papsch)(address . lists@rpapsch.de)(address . 21720@debbugs.gnu.org)
874mhkb2iu.fsf@gnu.org
Aljosha Papsch <lists@rpapsch.de> skribis:

Toggle quote (4 lines)
> 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.

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

Toggle quote (3 lines)
> 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.

Hmm, OK.

Toggle quote (5 lines)
> 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.

Is this deterministic? That is, does it happen again if you rerun ‘guix
build zile’ or something like that?

Toggle quote (3 lines)
> Makefile:2107: recipe for target 's-attrtab' failed
> make[2]: *** [s-attrtab] Killed

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’.
A
A
Andreas Enge wrote on 21 Oct 2015 18:59
(name . Ludovic Courtès)(address . ludo@gnu.org)
20151021165912.GA4970@debian
On Wed, Oct 21, 2015 at 06:38:17PM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> Sounds like binaries for 0.8.3 have been GC’d from hydra.gnu.org, which
> is unfortunate.

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
L
L
Ludovic Courtès wrote on 22 Oct 2015 01:12
(name . Andreas Enge)(address . andreas@enge.fr)
877fmfzui5.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (7 lines)
> On Wed, Oct 21, 2015 at 06:38:17PM +0200, Ludovic Courtès wrote:
>> Sounds like binaries for 0.8.3 have been GC’d from hydra.gnu.org, which
>> is unfortunate.
>
> Maybe after each release, we should create a profile with all the packages
> of this release (and delete it again after the next release)?

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

Toggle quote (2 lines)
> Or are we too low on disk space?

… probably.

Ludo’.
A
A
Aljosha Papsch wrote on 23 Oct 2015 01:04
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21720@debbugs.gnu.org)
56296B65.8000407@rpapsch.de
On 21.10.2015 18:38, Ludovic Courtès wrote:
Toggle quote (6 lines)
>> 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.
> Is this deterministic? That is, does it happen again if you rerun ‘guix
> build zile’ or something like that?
Yes, "guix build zile" fails again at GCCs build. I attached the build
log just to be sure.
Toggle quote (6 lines)
>> Makefile:2107: recipe for target 's-attrtab' failed
>> make[2]: *** [s-attrtab] Killed
> The “Killed” here suggests an out-of-memory condition. Does
> ‘dmesg | tail’ reveal something like that?
>
> How much memory does this machine have?
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
Attachment: 2kj5a59dymn0dhg0v09xqhc4hsxgsv-gcc-4.9.3.drv
Attachment: dmesg.log
A
A
Aljosha Papsch wrote on 23 Oct 2015 22:56
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21720@debbugs.gnu.org)
562A9EE4.3090702@rpapsch.de
On 23.10.2015 01:04, Aljosha Papsch wrote:
Toggle quote (3 lines)
> 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 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
Attachment: 6pakkby1qg17ssj4k9nrhh9iswii49-gcc-4.9.3.drv
Attachment: swap-plot.png
Attachment: memory-plot.png
E
E
Efraim Flashner wrote on 24 Oct 2015 22:35
(name . Aljosha Papsch)(address . lists@rpapsch.de)
20151024233554.244e404b@debian-netbook
On Fri, 23 Oct 2015 22:56:04 +0200
Aljosha Papsch <lists@rpapsch.de> wrote:

Toggle quote (10 lines)
> On 23.10.2015 01:04, Aljosha Papsch wrote:
> > 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 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.

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.

Toggle quote (19 lines)
>
> 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



--
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWK+uqAAoJEPTB05F+rO6TCcAP/2IJfqnj/Cu+4R+AZfD0tSky
w0YI6enSgEij9o2vjiqBSfdQ7p4D1nydS7ojhC7yIwJ076fxMtJ4GzEMCpPJzkCh
YfDPCKdic4ogoU6n+6hWEwfBNGdTMFCkmY7MC8cyrkDsEPJLjYEkkdS/8AMfBw3N
XyJGWuYQLWNWu4jUb8wvhudBVMEl8tNUZg/ZlEN2dq8F7CQJ2fzsfHv94EvyNGpA
E15bf2BuiJZugBoIkl6NBc+RVq6KNltuho8CHY0+8DhjhZBf9KsNKtIybmbYAuFw
xF4tU2yGMZkHvU6Nv+vTN19n8sIHmnznhUiN/N96SBSLUP938oUTH3W6xq8RNoYe
gYTymq2hLgbwpsKTIMAIijQHygZjw87vo+Ft8gaidQWH0ScGaIbTL+2sMoob0y6v
XLzaf694Bz3ArqJ9SxxKyHFMjVVo49GOv3RnZ2ngXiAaZj9CbHxfn5JIUaajDN2j
XFDn8swN166j8wlfOgYmyxLp793HxsD9efVFvl5HZ8jeicCWI/Pm4bUB+tTbuz9e
8BbrwqescG7Gp+3YGebr6D5BvwMDp9J2i5bSv5t3jMwV5VOavgA54CbVIgMOzF6p
GiF8q3DmAKC/ppxxOVoLPYZjkOV58FtlBHPpCtGere3Kgo35gSJLIIkDaY/n2JoV
DGJkycWy7tGiRQrePZwT
=M31O
-----END PGP SIGNATURE-----


E
E
Efraim Flashner wrote on 25 Oct 2015 14:25
(name . Aljosha Papsch)(address . lists@rpapsch.de)
20151025152523.6134d159@debian-netbook
On Sun, 25 Oct 2015 13:35:22 +0100
Aljosha Papsch <lists@rpapsch.de> wrote:

Toggle quote (23 lines)
> On 24.10.2015 22:35, Efraim Flashner 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.
>
> 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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWLNhDAAoJEPTB05F+rO6T9HwP/3nMG96JcPtCsNrLNJLupmVk
7uZDMeSxMnGiIo7YX3wrNKGiioHUbaKUIKiCrwBYzvPmK4u6doq6ylX9hZOGyf62
H7Q90oQH6U0jX3y7Y/d06H1e43Epg+bOd5ESxT+7acwzccG7ZEFJztXXNFd6Q1tE
maeX/6Q3tZFSTs21oHOn+6vPXjIisLEZi6Tqptru4EHAePrxpd5s804CXeZs95d3
URGXt69mgHEWMN2prDyp4g08n/oKlGKq75njhpOhlf6CWThVAnyA3hgZfe2RnZK9
DKzVYiWPczDAuPisPJHsbxNgeEN8Afy/V+LtweczPapj7ttMJe+UoaPUcc5HmOnU
XAaD/KePOtWdpIpW3Gl4Pppbqgqa2lcF6zEro8zQvC/IcfeRGmEz4bxKc66YQpCB
BdvJmRIYWFZfW8fkc/Ip/D97BAkZYElKkv27WGIOHu9Hq9hjUalUCKvxksmRmq3M
m2zgB4zpBGrnPzQ/SeoeWz3yqcG/XnkHaZHvnDa0KkBLDscatmBrw7BOA/6YPkMh
GZWoUREDYoFZg6/Uk89XMr029j7fNAzhZntm89Z2IQpeeTCk2GZPsP4kWbLK33P0
U5Fk7aGaqzoqzT9038su8OcK77sAKVriHFL1HxqjQxjy9dC7lnP0yj5rCjATV+XC
my1J1+hUw+Mq+DcnYJHG
=E3Dt
-----END PGP SIGNATURE-----


A
A
Aljosha Papsch wrote on 25 Oct 2015 13:35
(name . Efraim Flashner)(address . efraim@flashner.co.il)
562CCC8A.80407@rpapsch.de
On 24.10.2015 22:35, Efraim Flashner wrote:
Toggle quote (6 lines)
> 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.

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
L
L
Ludovic Courtès wrote on 25 Oct 2015 22:05
(name . Aljosha Papsch)(address . lists@rpapsch.de)(address . 21720@debbugs.gnu.org)
87io5umzgc.fsf@gnu.org
Aljosha Papsch <lists@rpapsch.de> skribis:

Toggle quote (2 lines)
> On 21.10.2015 18:38, Ludovic Courtès wrote:

[...]

Toggle quote (10 lines)
>> How much memory does this machine have?
> 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.

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.

Toggle quote (2 lines)
> [ 2779.152334] genattrtab invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0

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’.
L
L
Ludovic Courtès wrote on 25 Oct 2015 22:06
(name . Aljosha Papsch)(address . lists@rpapsch.de)
87a8r6mzdi.fsf@gnu.org
Aljosha Papsch <lists@rpapsch.de> skribis:

Toggle quote (10 lines)
> On 24.10.2015 22:35, Efraim Flashner 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.
>
> That was the nudge in the right direction. I didn't think of /tmp
> being mounted as tmpfs,

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

Well, thanks for finding it out!

Closing this bug now.

Ludo’.
L
L
Ludovic Courtès wrote on 25 Oct 2015 22:07
tag & close
(address . request@debbugs.gnu.org)
87611umzch.fsf@gnu.org
tag 21720 notabug
close 21720
thanks
?
Your comment

This issue is archived.

To comment on this conversation send an email to 21720@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 21720
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch