From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 04 17:00:21 2020 Received: (at submit) by debbugs.gnu.org; 4 Oct 2020 21:00:21 +0000 Received: from localhost ([127.0.0.1]:46859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPB7E-0006Bq-W0 for submit@debbugs.gnu.org; Sun, 04 Oct 2020 17:00:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:54188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPB7D-0006Bh-9Q for submit@debbugs.gnu.org; Sun, 04 Oct 2020 17:00:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPB7D-0007d5-0L for bug-guix@gnu.org; Sun, 04 Oct 2020 17:00:19 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:43016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPB7A-0001oV-Rl for bug-guix@gnu.org; Sun, 04 Oct 2020 17:00:18 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id DE76ABFB5D for ; Sun, 4 Oct 2020 21:00:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo04-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo04-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaH0LehUC8Vz for ; Sun, 4 Oct 2020 21:00:14 +0000 (UTC) Received: from laptop (unknown [108.162.141.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 8563DBFB2D for ; Sun, 4 Oct 2020 21:00:14 +0000 (UTC) From: Simon South To: bug-guix@gnu.org Subject: Knot: Linker runs very slowly and crashes during build Date: Sun, 04 Oct 2020 16:56:04 -0400 Message-ID: <87a6x1g17f.fsf@simonsouth.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.68.200.34; envelope-from=simon@simonsouth.net; helo=mailout.easymail.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/04 17:00:15 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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 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