From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed Date: Thu, 16 Apr 2020 20:24:15 +0100 Message-ID: <87mu7b5j4w.fsf@cbaines.net> References: <87369c8mus.fsf@cbaines.net> <87a73jy8y9.fsf@gnu.org> <87y2r37dy8.fsf@cbaines.net> <87h7xqrug3.fsf@gnu.org> <87pnc75ofc.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51447) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPA8F-0000mq-TF for bug-guix@gnu.org; Thu, 16 Apr 2020 15:25:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPA8E-0000Nc-F0 for bug-guix@gnu.org; Thu, 16 Apr 2020 15:25:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:56100) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jPA8E-0000NW-CS for bug-guix@gnu.org; Thu, 16 Apr 2020 15:25:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87pnc75ofc.fsf@cbaines.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 40525@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christopher Baines writes: > Ludovic Court=C3=A8s writes: > >> Hi Christopher, >> >> Christopher Baines skribis: >> >>> I've attached a script that when run should reproduce the issue. I >>> extracted the code relating to lint warnings from the Guix Data >>> Service. The script attached runs this code twice against the inferior, >>> once will often be enough to cause it to crash, but twice should >>> reproduce it more reliably. >> >> Thanks a lot. >> >> Here=E2=80=99s a backtrace from the core dumped by the inferior: > > ... > >> It could be an unbounded growth of libgc=E2=80=99s finalizer table or ou= r weak >> tables as we experienced in . >> >> We should be able to reproduce it with something like: >> >> guix time-machine --commit=3Dd523eb5c9c2659cbbaf4eeef3691234ae527ee6a = -- \ >> lint -c inputs-should-be-native,license,mirror-url,source-file-name,= source-unstable-tarball,derivation,patch-file-names,formatting,synopsis >> >> In top one can see that heap usage keeps growing, which may well be a >> bug in Guix proper rather than in Guile=E2=80=A6 but it doesn=E2=80=99t = crash. >> >> I would propose three actions here: >> >> 1. Run linters un =E2=80=98gcprof=E2=80=99 to see what=E2=80=99s eatin= g memory and hopefully >> find and address the leak. As a start, maybe just start reducing >> the list of checkers to see if there=E2=80=99s one of them that=E2= =80=99s causing >> it. >> >> The =E2=80=98derivation=E2=80=99 checker is definitely responsible = for a lot of the >> heap consumption because of the various caches in (guix packages) & >> co. Perhaps add calls to =E2=80=98invalidate-derivation-caches!=E2= =80=99 as in >> (gnu ci). >> >> 2. Work around the problem in Guix Data Service by running, say, one >> inferior per checker instead of one inferior for all checkers for >> all packages. >> >> 3. If #1 didn=E2=80=99t help, let=E2=80=99s see if we can isolate a Gu= ile weak-table >> bug or something like that. >> >> Thoughts? > > Thanks, that's useful to know. > > I think I've now managed to find a way of reproducing this without the > inferior getting in the way. I was testing if triggering garbage > collection in Guile would help avoid the problem, but actually it seems > to cause it. I guess given the mentions of GC in the above stacktrace, > and the major version change of libgc, some GC related bug seems quite > likely here. > > I've been testing with a checkout of Guix built with Guix from the > core-updates branch. I think that provides the same broken Guile that > the guix repl is using. > > When trying to just use a checkout of the core-updates branch, and guile > built from that branch I get the following odd error: > > =E2=86=92 ./pre-inst-env /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guil= e-3.0.2/bin/guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm > guile: warning: failed to install locale > warning: failed to load '(gnu packages abiword)': Function not implemented > error: git-fetch: unbound variable > hint: Did you forget `(use-modules (guix git-download))'? > > error: git-version: unbound variable > > > > No idea what's happening there, but when I ./configure and make with > packages from core-updates, I seem to end up with a setup that works: > > This is the guile I'm using: /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-= guile-3.0.2/bin/guile > > If you just run the script, you should see: > > =E2=86=92 ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-fa= iled.scm > > ;;; ("%package-table-setup" #) > mmap(PROT_NONE) failed > Aborted > > > For more information, you can pipe the script to the REPL. What you > should see is that it's slow to compute the lint warnings the first > time, but the subsequent times are quick, and it crashes in one of the > (gc) calls. > > I'm going to try and continue looking in to this, at least it'll be > easier to delve in to guile now that I can directly control what guile > is used. Following up on this, I've built Guile on core-updates with libgc@7 rather than libgc@8 (which is what's used above), and I can't reproduce the issue. So, I'm getting more certain that this is a regression which the libgc upgrade has led to. Would it be feasible to keep guile, or at least the guile Guix uses with libgc@7 for now? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl6YsN9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XfRzg/+Jjek7cTOieKUugglEHtEy74Mlj1EeMF+k07PRxMtfJouIyIjsEf1aDmJ q5Qk/4KT1/x7eABDIv9Mkkt6wldYtuDgOxrwIqMn8DHG+MQTs0gxRG9JPfVZ1BdF EhXG64XnuCDmQkjs26vmeia0rLtpoHoIulHTiGFE+/u+OUGdgto79GxSPAvdZaeV Je0nX5f2xOV7iZPwahdkzLVOEosMHvHTP2YsKfkbCgnkSjFz5sRfvXabaIYMtNu9 AdSPD13kkZ5zdsY7SONNFcOF7QL9bRIjIgX3hS9bj7H+Rp8dfTkp6HEDjHxumzCB eaZ9M8KaS4MGzeiwx8ztAVN5VC220I+4J9mwsu6y3jsHOoDoGBgEiJy8h3gCfOF2 kXJ3L0aBlCK3vnymOmWfM6HjRTaqxxv/ksmBfhEQmaOuCcl+juj0PJAayztvu9f1 lQoMhCFshHRUf17IgHkh7iYzWGU+is0rcWWnnFoDtZQ2S6JPW4vPn+G89ABcjikj vsnVj3Vy2JfobxJMBAWZESA4xC10C5uz8OCDpJB8/8VMCw9wknlXop6LE82ufocs DRVoy0X+08do+VgyRNiqgG4kmHh6QUyUEF6vGmc6qjzGvUwa79X/oIWVvCZXzscf I+xbfE7CQ1MJA5r8oejWzQY9isjKfJTe+gB7NZ6aWX0dJ7dYduo= =vLP9 -----END PGP SIGNATURE----- --=-=-=--