From: Simon South <simon@simonsouth.net>
To: 43802@debbugs.gnu.org
Subject: bug#43802: Knot: Linker runs very slowly and crashes during build
Date: Sun, 04 Oct 2020 16:56:04 -0400 [thread overview]
Message-ID: <87a6x1g17f.fsf@simonsouth.net> (raw)
Building Knot 3.0.0 using "guix build knot" consistently appears to hang
for me when it gets to this point during the linking stage:
CCLD knsec3hash
ar: `u' modifier ignored since `D' is the default (see `U')
CCLD kdig
CCLD khost
While it sits here the compiler is tying up 100% of a single CPU
core. On my ROCK64 with 4 GB of RAM, it eventually crashes with an
internal error:
gcc: internal compiler error: Killed (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [Makefile:5381: libzscanner/la-scanner.lo] Error 1
make[3]: Leaving directory '/tmp/guix-build-knot-3.0.0.drv-0/knot-3.0.0/src'
dmesg shows the compiler was killed for running out of memory:
cc1 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
CPU: 2 PID: 22340 Comm: cc1 Not tainted 5.8.11-gnu #1
(...)
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=cc1,pid=22340,uid=999
Out of memory: Killed process 22340 (cc1) total-vm:2573780kB, anon-rss:2540708kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:5044kB oom_score_adj:0
oom_reaper: reaped process 22340 (cc1), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
On my x86_64 machine the build eventually completes (that machine has
much more memory), but there is the same, weirdly long delay during
linking while the compiler runs.
I see no such delay however when I build the code "manually", using
"guix environment --pure knot" or even "guix environment --no-grafts
--container knot" as the manual suggests. The build then completes
quickly and successfully on either machine; the problem appears to
happen only when guix-daemon is involved.
Is there a known issue that can cause the linker to consume orders of
magnitude more resources when run by the Guix build process?
Apart from rebuilding gcc with debugging symbols (which seems to make
Guix want to rebuild every other package in the system as well) and
trying to understand what the compiler is doing, how might I go about
diagnosing this?
--
Simon South
simon@simonsouth.net
next reply other threads:[~2020-10-04 21:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-04 20:56 Simon South [this message]
2020-10-04 23:01 ` bug#43802: Knot: Linker runs very slowly and crashes during build Simon South
2020-10-05 0:09 ` Simon South
2020-10-05 15:26 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-10-05 15:44 ` Simon South
2020-10-07 22:06 ` Ludovic Courtès
2020-10-05 14:15 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6x1g17f.fsf@simonsouth.net \
--to=simon@simonsouth.net \
--cc=43802@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.